Социальная сеть Facebook анонсировала (https://www.facebook.com/notes/facebook-engineering/flashcac... новую значительную версию Flashcache 3.0 (https://github.com/facebook/flashcache), системы для прозрачного кэширования данных на быстрых SSD-накопителях, оформленной в виде модуля для ядра Linux, использующего фреймворк Device Mapper (http://en.wikipedia.org/wiki/Device_mapper) (DM). Поддерживается как кэширвоание чтения с блочных устройств, так и ускорение записи за счёт предварительного сохранения данных на SSD-накопитель с последующим сбросом данных на диск. Код проекта распространяется под лицензией GPLv2.
На базе новой версии Flashcache в Facebook уже развёрнута система массового кэширования данных, охватывающая тысячи серверов. По сравнению с прошлым выпуском переход на Flashcache 3.0 позволил на 40% снизить число операций чтения при обращении к жестким дискам и на 75% сократить интенсивность ввода/вывода при записи. Благодаря использованию более изощрённого алгоритма для принятия решения по помещению данных в кэш эффективность кэшировния удалось поднять с 60 до 80%, в среднем 80% всех обращений обрабатывается из кэша. Одновременно минимизировано появление невостребованных данных в кэше и осуществлён переход более равномерному распределению по кэшу часто обновляемых данных, что уменьшило нагрузку по записи данных на SSD-накопители.
Отмечается три ключевых улучшения в Flashcache 3.0:- Изменён алгоритм заполнения кэша, который позволил обеспечить более равномерное распределение данных. Анализ нагрузки на серверах с MySQL (InnoDB) показал, что большинство операций записи концентрируются в нескольких регионах диска, операции чтения также распределяются по диску неравномерно. В этой ситуации, используемая ранее схема линейного сопоставления 2 Мб блоков на диске с 2 Мб блоками в кэше приводила к тому что определённые области SSD-накопителей использовались излишне интенсивно, в то время как другие области простаивали. Для решения проблемы вместо линейной схемы задействован метод случайного хэширования, а также изменён размер блоков - блок на диске был уменьшен до 256 Кб, а блок в кэше увеличен до 16 Мб. В итоге, если раньше 80% всех дисковых операций концентрировались в 50% кэша, то теперь 50% кэша охватывает 50% дисковых операций.
<center><img src="http://www.opennet.me/opennews/pics_base/0_1381478472.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></center>- Переработана организация вытеснения неактуальных данных из кэша. Вместо ранее используемого алгоритма FIFO (http://ru.wikipedia.org/wiki/FIFO), подразумевающего вытеснение записей по времени их добавления, задействован алгоритм LRU (http://ru.wikipedia.org/wiki/Алгоритмы_кэширования), при котором записи вытесняются на основании давности обращения к ним. При использовании FIFO были нередки случаи когда единичные неактуальные данные замещали собой активно используемые записи, которые попали в кэш достаточно давно. Теперь в первую очередь из кэша вытесняются давно не используемые записи, независимо от порядка добавления данных в кэш. Задействована реализация LRU-2Q, подразумевающая помещение новых записей не в самый конец очереди на удаление, что позволяет сохранить 25% старых записей и исключить вытеснение старых записей в результате нетипичной пиковой активности, например при перестроении или миграции узла.
- Увеличение эффективности сброса данных на диск при кэшировании в режиме отложенной записи (write-back). Ранее сброс на диск осуществлялся при накоплении порции готовой для записи данных в привязке к сегментам кэша и активности в них, что приводило к неравномерной производительности частей кэша (некоторые данные сбрасывались периодически, а некоторые могли достаточно долго ожидать сброса на диск). В новой версии чистка и сброс данных отделён от кэширование на чтение и производится независимо от активности в кэше, что позволило сгладить производительность кэширования записи и выделить больше места на кэширование чтения.
URL: https://www.facebook.com/notes/facebook-engineering/flashcac...
Новость: http://www.opennet.me/opennews/art.shtml?num=38133
Куда ещё-то один, когда bcache уже аж в ядро принят и кроме него есть ещё и dm-cache, dm-writeboost и BTIER, как справедливо отмечено в похожих новостях?
dm-cache - это bcache вид с боку. flashcache - это версия bcache c оптимизацией для использования на ssd. остальное сырое..
bacache пока нельзя совместить с OpenVZ, например, а flashcache можно.
мы изобрели файловую систему, которая использует другую файловую систему, которая ...
в линуксе можно придумать контейнер с произвольным уровнем вложенности для любых обьектов
> мы изобрели файловую систему, которая использует другую файловую систему, которая ...
> в линуксе можно придумать контейнер с произвольным уровнем вложенности для любых обьектовнельзя :) это не фревый GEOM - тут все гвоздями прибито :)
Пиндабол. Лишь бы срaчь развести.Зыж
А нормальный (не брехлo) в первую очередь бы сказал — сабж вообще не fs, за такое в своё время можно было сессию провалить.
Лехко - через DM.
> схема линейного сопоставления 2 Мб блоков на диске с 2 Мб блоками в кэшеЭто как? Получается, размер кэша равен размеру хранилища за кэшем?
> изменён размер блоков - блок на диске был уменьшен до 256 Кб, а блок в кэше увеличен до 16 МбМолодцы, открыли для себя твикинг, который любой вменяемый админ выполняет сразу после установки.
И кстати, из текста никак не следует, что пространство внутри блока 16MB будет использоваться равномерно. Не удивлюсь, если SSD будет изношен полосками - 2MB изношено, 14MB свежие.
да не будет SSD изношен, внутри он сам обеспечивает равномерное использование всех блоков. Тем более юзерспейс обычно не знает какой физический размер блока внтури девайса (обычно несколько мб) и, следовательно, не может правильно выбрать стратегию распределения. Это древняя проблема из-за которой зафейлились некоторые flash-fs
Какой это по счету кэшь на ССД?
Посдкажите: я могу на десктопе использовать китайскую флешку, для ускорения операций с HDD? что для этого лучше настроить? dm-cache?
2. какой объем флешки необходим? чем больше тем лучше? (допустим у меня винт 256ГБ, флешка 2ГБ)
3. в каком режиме можно не бояться за данные, если флешка выйдет из строя?
Если китайская флешка - это SSD-диск нормального производителя, то да, можешь.Ещё лучше если твоя китайская флешка имеет надпись "Fusion-IO" и подключается сразу в PCI-Express. Можно даже с другими надписями, но с PCI-Express. На крайний случай пойдёт и SATA.
Чтобы было "лучше" также важно определится со своими запросами и протестировать все имеющиеся реализации кеша именно на твоих задачах. Реализаций пока всего 3 ( три ).
Точного ответа какая реализация лучше пока нет, т.к. они все появились относительно недавно, а две из них, включенные в ядро, в нём оказались только в этом году. Да и задачи у людей различаются.
На github до сих пор 2-ая версия лежит. Кто-нибудь знает, где скачать 3-ю?
я вот тоже решил попроовать - а кода-то и нет. просто не успели выложить? Но победная реляция была 2 дня назад ( October 9, 2013 at 10:01am ). Странно как-то...
Грустно. Такие титанические полеты мысли и траты ресурсов планеты, а всё ради того чтобы у хомячков какой-нибудь "музончик с инета" не тормозил.
