Сравнение bcache и btier

После моего предыдущего поста о bcache ^[1], мне посоветовали использовать более быстрый btier. Через некоторое время появилась возможность попробовать его в боевых условиях. Этот пост будет о сравнении двух разных подоходов к ускорению работы жестких дисков…

Bcache

Bcache ^[2] делает ставку на кэширование данных. Если данные были прочитаны один или несколько раз, они скорее всего осядут в кэше и следующий раз будут прочитаны из кэша. Основное ускорение получается при кэшировании операций случайного чтения. Потому как операции последовательного чтения, по мнению bcache, вряд ли получится ускорить, а также большой файл не вытеснит из кэша много мелких. Но тут возникает проблема, как определить, будет ли только начавшаяся операция чтения последовательной, или их будет много и к разным мелким файлам? Можно конечно для каждого процесса кэшировать последние N блоков и если все N+1 блок идут в подряд — не заносить эти данные в кэш. В таком случае будет большая нагрузка на память и решение о длинне операции чтения мы получим только когда эта длинна превысила или не превысила какой-то порог. Bcache использует другое решение. Для каждого процесса хранится скользящая средняя длинна операции чтения. Если она длиннее параметра sequential_cutoff — в кэш прочитанные данные процесса не попадут. Еще одно интересное решение, заслуживающее упоминания — это порог высокой нагрузки. Допустим если пришло одновременно много запросов на операции чтения и все они приходятся на данные, которые лежат в кэше. Кэш будет перегружен, а hdd будет простаивать. Для таких случаев есть параметр congested_read_threshold, который задает время в миллисекундах, которое операция чтения ждет в очереди кэша, после чего запрос уходит к hdd. Такой же параметр есть и для операции записи. Вся эта механика настраивается или отключается по желанию, что очень полезно, когда надо подогнать параметры работы bcache под тяжелую задачу.

Достоинства

• Гибкие параметры конфигурации.
• Наполнение кэша во время работы тяжелых задач.
• Автоматическая инициализация во время загрузки.
• Может работать в режиме кэширования как чтения, так чтения и записи.
• Входит в состав ядра с версии 3.10.

Недостатки

• Прежде чем кэш будет приносить пользу, его надо заполнить, а прирост скорости не будет мгновенным.
• Если у процесс читает большой файл и вместе с этим часто обращается к мелким файлам — эти частые мелкие операции чтения скорее всего не попадут в кэш, хотя они могли бы серьезно ускорить работу.
• В кэше не может быть несколько SSD дисков.

Btier

Btier ^[3] много проще, но не значит что хуже. :) Он просто использует другой подход для ускорения работы с данными — многослойные диски (подскажите более точный перевод). Идея очень проста: диски склеиваются между собой от более быстрого, к более медленному. Блоки данных, которые чаще используют — переносятся на быстрый диск, блоки данных, которые давно не использовались — переносятся на медленный диск. Миграция происходит с настраиваемым интервалом. Но если кто-то активно использует диск — миграция проведена не будет. Статистика популярности блоков накапливается за отрезок времени и если к блоку не было обращений — он мигрирует на самый медленный диск. Все просто, достаточно быстро и для некоторых задач весьма эффективно.

Достоинства

• Можно объединить несколько дисков.
• Обьем ssd дисков прибавляется к общему обьему.
• Во время роста btier данные помещаются в первую очередь на быстрые диски.
• Высокая скорость после начала работы.
• Легко собирается как модуль к текущему ядру.

Недостатки

• Надежность как у RAID-0
• Миграция происходит, когда btier простаивает. Во время тяжелой для диска задачи можно не надеяться что данные мигрируют на более быстрый диск.
• Если мы некоторе время на запускали тяжелых задач на разделе с btier — все данные постепенно мигрируют на самый медленный диск.

Итог

Универсального решения не существует. Так же нельзя сказать, что btier лучше чем bcache, или bcache лучше чем btier. Они помогают в решении одной проблемы. Но их эффективность очень зависит от конкретной задачи. Я импортирую данные OpenStreetMap в базу данных и стараюсь ускорить этот процесс. Для этой задачи bcache подходит лучше, т.к. вся работа упирается в iops и скорость диска — он быстрее кэширует необходимые данные на ssd и достаточно быстро адаптируется под нужды процесса импорта. С другой стороны после импорта приходится выполнять очень много запросов по получившейся базе данных и запросы эти, часть времени упираются в процессор, а часть времени в диск. В этом случае btier сможет в момент простоя диска мигрировать популярные блоки на ssd и ускорить работу запросов, которые раньше упирались в диск.

Автор: mOlind

Источник ^[4]