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

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

    image

    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 и ускорить работу запросов, которые раньше упирались в диск.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 13
    • +2
      Спасибо. Про btier я не слышал, а штука крайне интересная. Поставил в список технологий на изучение.
      • 0
        ждём нормального обзора и тестов :_)
      • 0
        Получается, что когда кеширование так нужно (начали активно обращаться к части данных), оно не работает? А в эту штуку можно непрерывным потоком (пусть и не особо большим) записать данных больше, чем объём SSD диска? Оба вопроса проистекают из фразы о том, что миграция запускается, когда btier простаивает.
        • 0
          Объем btier = ssd + hdd как на крайней правой схеме в начале статьи. Можно записывать файлы без ограничений по размеру. Хоть в 2 раза больше чем ssd. Только вы не можете насильно сказать системе что должно быть на ssd, а что нет. Она сама решает.
          • 0
            Запись не всегда всегда сначала на SSD падает?
            • 0
              Четкого ответа на этот вопрос у меня нет. Есть только практические наблюдения: У btier есть такой параметр как allocated size — обьем блоков, в которые файловая система уже что-то писала. Когда этот allocated size рос — он записывал на SSD в первую очередь. Когда я почистил файлы на диске — allocated size остался прежним. И новые файлы писались уже без роста allocated size. В моем случае все они попали на hdd.
        • 0
          Прежде чем кэш будет приносить пользу, его надо заполнить, а прирост скорости не будет мгновенным.

          А как же кэш на запись? Ведь кэшируется не только чтение, но и запись, а запись более дорогая операция, так как кэш самого жесткого диска может для нее не использоваться(так как энергозависим), а SSD может использоваться, так как энергонезависим.
          • 0
            По умолчанию writeback выключен, т.к. он понижает надежность до той же что у btier. Так что в этом предложении я имел ввиду кэширование чтения.
          • +1
            В кэше не может быть несколько SSD дисков.
            В первой ссылке по запросу bcache HOWTO утверждается, что как местом расположения кэша, так и местом расположения HDD может быть любое блочное устройство. Любое — это значит, что вы можете поставить там RAID0 из SSD, LVM раздел или даже другую пару устройств под управлением bcache (хотя это и не имеет смысла).

            Другой вопрос, что именно надо поставить, чтобы уменьшить время доступа (в интернете утверждают, что кэшировать на RAID0 из SSD не имеет смысла, так как это увеличит задержки; не знаю, насколько можно им верить). Но тот же LVM может склеивать диски последовательно ⇒ не увеличивая время доступа. Хотя, конечно, если бы данные по дискам раскидывал сам bcache, то можно было бы оптимизировать алгоритм.
            • 0
              Да, все верно. Но это обходные пути, которые надо подключать к bcache вместо прямого доступа к диску. У bcache в документации сказано, что они работают с cache set-ами. Но на текущем этапе развития проекта в cache set-e может быть только один SSD.
            • 0
              Меня bcache больше всего привлекает реакцией на сценарий «ssd накрылся»
              • 0
                Есть у меня цитата по этому поводу из свежего лога:
                [236703.540244] EXT4-fs warning (device bcache0): ext4_end_bio:332: I/O error writing to inode 44040362 (offset 0 size 0 starting block 126647204)
                [236703.560457] EXT4-fs warning (device bcache0): ext4_end_bio:332: I/O error writing to inode 44040510 (offset 0 size 0 starting block 140103448)
                [238784.354788] bcache: cached_dev_detach_finish() Caching disabled for sdc6
                [238784.462924] bcache: cache_set_free() Cache set 4b7f2878-bb7f-4f43-ab6b-03611d38b604 unregistered
                

                Со стороны приложений падение кэша осталось незамеченым.
              • 0
                А закончилось тем, что собрал RAID0 из 3х ssd. Теперь никаких затыков с доступом к файлам. :)

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.