Pull to refresh

Comments 18

Настоящий гентушник не ждет ебилды, а пишет их!
на DUMP'е Антон Халиков из NetAngels делал еще весной замечательный доклад про flashcache с циферками реального боевого применения на их хостинге. Поищите — будет интересно
Как раз я там на видео Антона терзал за память. Ибо мы для редких пиковых нагрузок как раз используем для отдачи видео кеш в памяти. Но там tempfs и скрипты для анализа пиков. Flashcache нравится, только ssd не дают :-( Не корпоративный стандарт, хехе
Кстати, если данные не жалко (в смысле, есть речь про кеш или что-то подобное), то флешкеш можно строить поверх block ram disk. В этом случае оно отжигает не-подетски.
Всмысле ramdisk в качестве кеша для медленного блочного девайса? А в чем прикол? И так ведь есть файловый кеш в RAM?
Если данных не жалко — все flush операции (включая транзакции в БД) будут обманывать софт и выполняться в ramcache. Итоговая производительность будет запредельная, latency низкая, любое отключение питания не просто даёт «немного дисковых ошибок», но полностью сносит любые следы разумной ФС на нижележащем устройстве.

Кстати, касается и сдыхающей ssd'шки в wb-режиме. Дохнет — забыли про данные.
В нашем случае там рамдиск в 1Gb как отдельный девайс. Без flashcache. А что такое потери данных в терабайты по причине вылета fs, мы знаем на собственном горьком опыте. Бекап тут нереален ввиду бюджетности (просто потому что вторые 10 Тб взять просто негде). Но и данные не столь критичны
Я читал Вашу статью. К сожалению, не нашёл в ней информации об установке и настройке. Кстати, я так понимаю, Вы используете режим writeback в продакшене? Как оно? Не боитесь потери данных при сбое?
Установка и настройка есть в ридми.
writeback работает нормально, причин для беспокойства нет.
Потери при сбое будут практически такими же, как при отключеном на ходу питании — так зачем бояться?
Sign up to leave a comment.

Articles