Социальная сеть 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