После моего предыдущего поста о bcache, мне посоветовали использовать более быстрый btier. Через некоторое время появилась возможность попробовать его в боевых условиях. Этот пост будет о сравнении двух разных подоходов к ускорению работы жестких дисков…
Bcache делает ставку на кэширование данных. Если данные были прочитаны один или несколько раз, они скорее всего осядут в кэше и следующий раз будут прочитаны из кэша. Основное ускорение получается при кэшировании операций случайного чтения. Потому как операции последовательного чтения, по мнению bcache, вряд ли получится ускорить, а также большой файл не вытеснит из кэша много мелких. Но тут возникает проблема, как определить, будет ли только начавшаяся операция чтения последовательной, или их будет много и к разным мелким файлам? Можно конечно для каждого процесса кэшировать последние N блоков и если все N+1 блок идут в подряд — не заносить эти данные в кэш. В таком случае будет большая нагрузка на память и решение о длинне операции чтения мы получим только когда эта длинна превысила или не превысила какой-то порог. Bcache использует другое решение. Для каждого процесса хранится скользящая средняя длинна операции чтения. Если она длиннее параметра sequential_cutoff — в кэш прочитанные данные процесса не попадут. Еще одно интересное решение, заслуживающее упоминания — это порог высокой нагрузки. Допустим если пришло одновременно много запросов на операции чтения и все они приходятся на данные, которые лежат в кэше. Кэш будет перегружен, а hdd будет простаивать. Для таких случаев есть параметр congested_read_threshold, который задает время в миллисекундах, которое операция чтения ждет в очереди кэша, после чего запрос уходит к hdd. Такой же параметр есть и для операции записи. Вся эта механика настраивается или отключается по желанию, что очень полезно, когда надо подогнать параметры работы bcache под тяжелую задачу.
Btier много проще, но не значит что хуже. :) Он просто использует другой подход для ускорения работы с данными — многослойные диски (подскажите более точный перевод). Идея очень проста: диски склеиваются между собой от более быстрого, к более медленному. Блоки данных, которые чаще используют — переносятся на быстрый диск, блоки данных, которые давно не использовались — переносятся на медленный диск. Миграция происходит с настраиваемым интервалом. Но если кто-то активно использует диск — миграция проведена не будет. Статистика популярности блоков накапливается за отрезок времени и если к блоку не было обращений — он мигрирует на самый медленный диск. Все просто, достаточно быстро и для некоторых задач весьма эффективно.
Универсального решения не существует. Так же нельзя сказать, что btier лучше чем bcache, или bcache лучше чем btier. Они помогают в решении одной проблемы. Но их эффективность очень зависит от конкретной задачи. Я импортирую данные OpenStreetMap в базу данных и стараюсь ускорить этот процесс. Для этой задачи bcache подходит лучше, т.к. вся работа упирается в iops и скорость диска — он быстрее кэширует необходимые данные на ssd и достаточно быстро адаптируется под нужды процесса импорта. С другой стороны после импорта приходится выполнять очень много запросов по получившейся базе данных и запросы эти, часть времени упираются в процессор, а часть времени в диск. В этом случае btier сможет в момент простоя диска мигрировать популярные блоки на ssd и ускорить работу запросов, которые раньше упирались в диск.
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 и ускорить работу запросов, которые раньше упирались в диск.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers.
Комментариев нет:
Отправить комментарий