После моего предыдущего поста о bcache, мне посоветовали использовать более быстрый btier. Через некоторое время появилась возможность попробовать его в боевых условиях. Этот пост будет о сравнении двух разных подоходов к ускорению работы жестких дисков…
Bcache
Bcache делает ставку на кэширование данных. Если данные были прочитаны один или несколько раз, они скорее всего осядут в кэше и следующий раз будут прочитаны из кэша. Основное ускорение получается при кэшировании операций случайного чтения. Потому как операции последовательного чтения, по мнению bcache, вряд ли получится ускорить, а также большой файл не вытеснит из кэша много мелких. Но тут возникает проблема, как определить, будет ли только начавшаяся операция чтения последовательной, или их будет много и к разным мелким файлам? Можно конечно для каждого процесса кэшировать последние N блоков и если все N+1 блок идут в подряд — не заносить эти данные в кэш. В таком случае будет большая нагрузка на память и решение о длинне операции чтения мы получим только когда эта длинна превысила или не превысила какой-то порог. Bcache использует другое решение. Для каждого процесса хранится скользящая средняя длинна операции чтения. Если она длиннее параметра sequential_cutoff — в кэш прочитанные данные процесса не попадут. Еще одно интересное решение, заслуживающее упоминания — это порог высокой нагрузки. Допустим если пришло одновременно много запросов на операции чтения и все они приходятся на данные, которые лежат в кэше. Кэш будет перегружен, а hdd будет простаивать. Для таких случаев есть параметр congested_read_threshold, который задает время в миллисекундах, которое операция чтения ждет в очереди кэша, после чего запрос уходит к hdd. Такой же параметр есть и для операции записи. Вся эта механика настраивается или отключается по желанию, что очень полезно, когда надо подогнать параметры работы bcache под тяжелую задачу.
Достоинства
- Гибкие параметры конфигурации.
- Наполнение кэша во время работы тяжелых задач.
- Автоматическая инициализация во время загрузки.
- Может работать в режиме кэширования как чтения, так чтения и записи.
- Входит в состав ядра с версии 3.10.
Недостатки
- Прежде чем кэш будет приносить пользу, его надо заполнить, а прирост скорости не будет мгновенным.
- Если у процесс читает большой файл и вместе с этим часто обращается к мелким файлам — эти частые мелкие операции чтения скорее всего не попадут в кэш, хотя они могли бы серьезно ускорить работу.
- В кэше не может быть несколько SSD дисков.
Btier
Btier много проще, но не значит что хуже. :) Он просто использует другой подход для ускорения работы с данными — многослойные диски (подскажите более точный перевод). Идея очень проста: диски склеиваются между собой от более быстрого, к более медленному. Блоки данных, которые чаще используют — переносятся на быстрый диск, блоки данных, которые давно не использовались — переносятся на медленный диск. Миграция происходит с настраиваемым интервалом. Но если кто-то активно использует диск — миграция проведена не будет. Статистика популярности блоков накапливается за отрезок времени и если к блоку не было обращений — он мигрирует на самый медленный диск. Все просто, достаточно быстро и для некоторых задач весьма эффективно.
Достоинства
- Можно объединить несколько дисков.
- Обьем ssd дисков прибавляется к общему обьему.
- Во время роста btier данные помещаются в первую очередь на быстрые диски.
- Высокая скорость после начала работы.
- Легко собирается как модуль к текущему ядру.
Недостатки
- Надежность как у RAID-0
- Миграция происходит, когда btier простаивает. Во время тяжелой для диска задачи можно не надеяться что данные мигрируют на более быстрый диск.
- Если мы некоторе время на запускали тяжелых задач на разделе с btier — все данные постепенно мигрируют на самый медленный диск.
Итог
Универсального решения не существует. Так же нельзя сказать, что btier лучше чем bcache, или bcache лучше чем btier. Они помогают в решении одной проблемы. Но их эффективность очень зависит от конкретной задачи. Я импортирую данные OpenStreetMap в базу данных и стараюсь ускорить этот процесс. Для этой задачи bcache подходит лучше, т.к. вся работа упирается в iops и скорость диска — он быстрее кэширует необходимые данные на ssd и достаточно быстро адаптируется под нужды процесса импорта. С другой стороны после импорта приходится выполнять очень много запросов по получившейся базе данных и запросы эти, часть времени упираются в процессор, а часть времени в диск. В этом случае btier сможет в момент простоя диска мигрировать популярные блоки на ssd и ускорить работу запросов, которые раньше упирались в диск.
Автор: mOlind
