Производительность mdadm raid 5,6,10 и ZFS zraid, zraid2, ZFS striped mirror

    Тестируем производительность ZFS и mdadm+ext4 на SSD Sandisk CloudSpeed
    для выбора технологии создания локального дискового массива.


    Цель данного тестирования — выяснить, с какой реальной скоростью смогут работать виртуальные машины в raw файловых образах, если разместить их на 4-х производительных SSD-дисках. Тестирование будет производится в 32 потока, чтобы приблизительно создать условия работы реального гипервизора.

    image




    Замеры будем производить при помощи инструмента fio.

    Для mdadm+ext4 были выбраны опции --buffered=0 --direct=1. ZFS не умеет работать с этими опциями, поэтому ожидается, что результат ZFS будет несколько выше. Для сравнения я также отключу эти опции в одном из тестов и для варианта с mdadm.

    Мы будем проводить тест с файлом размером в 10ГБ. Предположительно, что этого размера достаточно, чтобы оценить производительность файловой системы при выполнении рутинных операций. Разумеется, если увеличить объем тестовых данных, то общие цифры по всем тестам будут значительно ниже, так как мы сведем на нет все дополнительные средства кеширования и предсказания на файловых системах. Но такой цели нет. Нам нужны не сухие цифры синтетического тестирования, а что-то более приближенное к реальной жизни.

    В качестве тестового стенда используем следующую конфигурацию:


    Производитель:
    Supermicro X9DRT-HF+

    Процессоры:
    2x Intel® Xeon® CPU E5-2690 0 @ 2.90GHz C2
    Техпроцесс — 32 нм
    Количество ядер — 8
    Количество потоков — 16
    Базовая частота процессора — 2,90 ГГц
    Максимальная турбо частота — 3,80 ГГц
    Кэш 20 МБ SmartCache
    Скорость шины — 8 GT/s QPI
    TDP — 135 Вт

    Оперативная память:
    16x 16384 MB
    Тип: DDR3 Registered (Buffered)
    Частота: 1333 MHz
    Производитель: Micron

    Дисковый контроллер:
    LSI SAS 2008 RAID IT mode

    Твердотельные диски:
    4x 1.92Tb SSD Sandisk CloudSpeed ECO Gen. II
    SSD, 2.5", 1920 Гб, SATA-III, чтение: 530 Мб/сек, запись: 460 Мб/сек, MLC
    Заявленный IOPS произвольного чтения/записи 76000/14000 IOPS
    Время наработки на отказ 2000000 ч.

    Ядро:
    Linux 4.13.4-1-pve #1 SMP PVE 4.13.4-26 (Mon, 6 Nov 2017 11:23:55 +0100) x86_64

    Версия ZFS:
    v0.7.3-1

    Планировщик IO:

    cat /sys/block/sdb/queue/scheduler
    [noop] deadline cfq

    Тестовый инструмент:
    fio-2.16

    Параметры сборки массивов


    # Параметры создания ZFS массива на одном диске

    zpool create -f -o ashift=12 /dev/sdb

    # Параметры создания zraid (raid5 аналога на ZFS)

    zpool create -f -o ashift=12 test raidz /dev/sdb /dev/sdc /dev/sdd /dev/sde

    # Параметры создания zraid2 (raid6 аналога на ZFS)

    zpool create -f -o ashift=12 test raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde

    # Параметры создания striped mirror (raid10 аналога на ZFS)

    zpool create -f -o ashift=12 test mirror sdb sdc mirror sdd sde

    # Общие параметры для ZFS массивов

    ZFS set atime=off test
    ZFS set compression=off test
    ZFS set dedup=off test
    ZFS set primarycache=all test

    Под arc выделено 1/4 всей памяти или 52 ГБ

    cat /etc/modprobe.d/ZFS.conf
    options ZFS zfs_arc_max=55834574848

    # Параметры создания массива mdadm raid5

    mdadm --zero-superblock  /dev/sd[bcde]
    mdadm --create --verbose --force --assume-clean --bitmap=internal --bitmap-chunk=131072 /dev/md0 --level=5  --raid-devices=4  /dev/sd[bcde]

    # Параметры создания массива mdadm raid6

    mdadm --zero-superblock  /dev/sd[bcde]
    mdadm --create --verbose --force --assume-clean --bitmap=internal --bitmap-chunk=131072 /dev/md0 --level=6  --raid-devices=4  /dev/sd[bcde]

    # Общие параметры для mdadm 5/6 массивов

    echo 32768 > /sys/block/md0/md/stripe_cache_size
    blockdev --setra 65536 /dev/md0
    echo 600000 > /proc/sys/dev/raid/speed_limit_max
    echo 600000 > /proc/sys/dev/raid/speed_limit_min

    # Параметры создания массива mdadm raid10

    mdadm --zero-superblock  /dev/sd[bcde]
    mdadm --create --verbose --force --assume-clean --bitmap=internal --bitmap-chunk=131072 /dev/md0 --level=10  --raid-devices=4  /dev/sd[bcde]

    # Параметры создания таблицы разметки GPT

    parted -a optimal /dev/md0
    mktable gpt 
    mkpart primary 0% 100%
    q

    # Параметры создания ext4 файловой системы

    mkfs.ext4 -m 0  -b 4096 -E stride=128,stripe-width=256 /dev/md0p1 (/dev/sdb)
    Где stripe-width=256 для raid6 и raid10 и stripe-width=384 для raid5

    # Параметры монтирования ext4 файловой системы в fstab

    UUID="xxxxx" /test ext4 defaults,noatime,lazytime 1 2


    Результаты




    fio --directory=/test/ --name=read --rw=read --bs=4k --size=200G --numjobs=1 --time_based --runtime=60 --group_reporting --ioengine libaio --iodepth=32 
    # Для ext4 + параметры --buffered=0 --direct=1



    В тесте на чтение явно видно влияние буфера ARC на работу файловой системы ZFS. ZFS демонстрирует ровную и высокую скорость во всех тестах. Если выключить --buffered=0 --direct=1 скорость на mdadm raid10 + ext4 по ZFS оказывается в 3 раза медленнее и в 10 раз медленнее по части задержек и IOPS.

    Наличие дополнительных дисков в zraid не дает существенного прироста скорости для ZFS. ZFS 0+1 — это так же медленно, как и zraid.

    fio --directory=/ --name=test --rw=randread --bs=4k --size=10G --numjobs=1 --time_based --runtime=60 --group_reporting --ioengine libaio --iodepth=32 --buffered=0 --direct=1
    # Для ext4 + параметры --buffered=0 --direct=1



    Вот тут ARC никак не спасает ZFS. Цифры наглядно показывают положение дел.

    fio --directory=/ --name=test --rw=write --bs=4k --size=10G --numjobs=1 --group_reporting --ioengine libaio --iodepth=32 --buffered=0 --direct=1
    # Для ext4 + параметры --buffered=0 --direct=1



    Опять же, буферы помогают ZFS давать ровный результат на всех массивах. mdadm raid6 явно пасует перед raid5 и raid10. Буферизированный и кэшированный mdadm raid10 дает вдвое лучший результат через все варианты на ZFS.

    fio --directory=/ --name=test --rw=randwrite --bs=4k --size=10G --numjobs=1 --group_reporting --ioengine libaio --iodepth=32 --buffered=0 --direct=1
    # Для ext4 + параметры --buffered=0 --direct=1



    Картина аналогичная и по случайному чтению. ZFS не помогают его буферы и кеши. Он сливает со страшной силой. Особенно пугает результат одиночного диска на ZFS и в целом результаты по ZFS отвратительные.

    По mdadm raid5/6 все ожидаемо. Raid5 медленный, raid6 еще медленней, а raid10 примерно на 25-30 % быстрее одиночного диска. Raid10 с буферизацией уносит массив в космос.

    Выводы


    Как всем известно, ZFS не быстр.

    Он содержит десятки других важных возможностей и достоинств, но это не отменяет того факта, что он существенно медленнее, чем mdadm+ext4, даже с учетом работы кешей и буферов, систем предсказаний и так далее. По этой части неожиданностей нет.

    ZFS версий v0.7.x не стал существенно быстрее.

    Возможно, быстрее чем v0.6.x, но далек до mdadm+ext4.

    Можно найти информацию, что zraid/2 — это улучшенная версия raid5/6, но не по части производительности.

    Использование zraid/2 или 0+1 не позволяет добиться более высокой скорости от массива, чем одиночный диск ZFS.

    В лучшем случае, скорость будет не ниже или совсем немного выше. В худшем, наличие дополнительных дисков замедлит общую скорость работы. Raid для ZFS — это средство повышения надежности, но не производительности.

    Наличие большого ARC не позволит компенсировать отставание ZFS по производительности относительно того же ext4.

    Как вы можете увидеть, даже буфер размером в 50 ГБ не способен существенно помочь ZFS не отставать от младшего брата EXT4. Особенно на операциях случайной записи и чтения.

    Использовать ли ZFS для виртуализации?

    Каждый ответит сам. Лично я отказался от ZFS в пользу mdadm + raid10.

    Спасибо Вам большое за внимание.
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 65
    • –1

      Классический Raid на SSD не самое удачное решение. Для Raid 5/6 ещё куда ни шло, хотя уже существуют более удачные для SSD варианты: разнообразные "матричные" решения в проприетарных сторожах. А вот RAID10 выглядит очень плохим вариантом из-за низкой надежности. Дело в том, что HDD умерали по механическим причинам и даже при равномерной нагрузке поломки проиходили в разное время. А вот SSD умирает по счетчику и при равномерной нагрузке очень велика вероятность близкого к одновременному выходу из строя.

      • 0
        Спасибо, а какова альтернатива? если не считать железные проприетарные решения?
        • 0

          Пока не видел.

          • 0
            Аналогичная проблема. Главное делать бекапы )
          • +1
            А насколько вообще реальна проблема? В «enterprise» системах счетчик по которому «умирает» SSD многократно перекрывает ожидаемое время эксплуатации системы. У нас вот ЕМСшному SANу пошел шестой год — ни одной замены SSD, VTL от Quantum — аналочно, NetApp-овский NAS — та-же история. Даже SSD на терминалах горят исключительно редко…
          • 0
            По этому мы заменяем SSD в рейдах планово, через промежутки времени.
            • +1

              Вроде тут какой-то крупный хостер говорил, что они тупо ставят чипы разного производителя в зеркало.

            • 0
              Как часто?
              • 0
                Пол-года год, в зависимости от нагруженности железки. Потом эти диски идут на что-нибудь менее ответственное.
                • 0
                  Спасибо, прогноз не утешительный. Интересно, у них MLC диски были?
                  • 0
                    Если так быстро они у вас подходят к границе, то были случаи, что диски выходил из строя из-за полного исчерпания ресурса перезаписи ячеек?
                    * А то ходят легенды, что еще ни один новый SSD не умер по причине исчерпания ресурса перезаписи в ячейках (ну, возможно, с учетом резервных ячеек).
                    • 0
                      За этот срок они не подходят к границе, тестирование выведенных из эксплуатации показывает, что им еще работать и работать. Это делается именно для исключения ситуации «исчерпали ресурс все вместе». Насколько я знаю, сейчас срок ратирования увеличили.
                      Полного исчерпания не было, но вот несколько SSD со скоростью работы USB-флешки я наблюдал. гораздо больше их попередохло из-за выхода из строя контроллеров.
            • +1
              Мы будем проводить тест с файлом размером в 10ГБ. Предположительно, что этого размера достаточно, чтобы оценить производительность файловой системы при выполнении рутинных операций. Разумеется, если увеличить объем тестовых данных, то общие цифры по всем тестам будут значительно ниже, так как мы сведем на нет все дополнительные средства кеширования и предсказания на файловых системах.

              Иными словами, померяли непонятно что. :)


              Во-первых, если вы пытаетесь оценить "реальную работу гипервизора", то это даже близко не сценарий "10Гб горячих данных в одном файле". Данные, как минимум, разнесены по разным файлам, что должно существенно влиять на поведение файловой системы при кэшировании. Хотите тестировать именно такой паттерн нагрузки — для этого есть специальные тесты, а пытаться эмулировать его таким образом — заведомо получать результаты, которые с реальностью будут коррелировать не пойми как.


              Во-вторых, нет даже попытки анализа (хотя бы загрузки процессора и потребление памяти дополнительно). 2K иопс на запись, серьезно? И во что упираемся? По мне так похоже на какие-то проблемы с конфигурацией. При этом у вас на ext4 на запись 43К iops, что втрое превосходит официальный максимум по спекам производителя ("до 14K"). Это на фоне того, что по случайном чтению вы до них, наоборот, серьезно недотягиваете. Вопрос "что намеряли" возникает сам собой.

              • 0
                Как раз это вполне реальная ситуация. Когда в 1 raw файл образа диска идет некоторое количество одновременных потоков. В нашем случае 32.
                Что касается загрузки ЦПУ и расхода памяти, то на данной конфигурации они были минимальны и я ими пренебрёг так как это не играет для меня существенной роли.

                Какие официальные спеки? Какие проблемы с конфигурацией? Какие специальные тесты?
                Был бы благодарен за большее количество конкретики.
                • +3
                  Какие официальные спеки?

                  Вашего оборудования. https://www.sandisk.com/business/datacenter/resources/data-sheets/cloudspeed-eco-genii-sata-ssd-datasheet


                  Какие проблемы с конфигурацией?

                  Не знаю. У меня нет такого опыта работы с ZFS, чтобы сходу понять, что у вас не так, но есть опыт, говорящий, что просто от смены одной современной локальной файловой системы на другую производительность в почти 20 раз не меняется. Если комментатор ниже прав и вы действительно в силу устройства ZFS на самом деле протестировали не 4K, а 128К блоки, то перед окончательными выводами о медленности ZFS надо как минимум настройку под задачу сделать.


                  UPD. Под RAID-5/6 на SSD вообще рекомендуется отдельные накопители для журналирования выделять, не только ZFS касается, кстати.


                  Какие специальные тесты?

                  Под линукс так сходу не назову. В принципе с помощью fio вы практически любую нагрузку можете эмулировать, но только надо знать, как. 32 qd в один 10GB файл мне не кажется разумным приближением к задаче.

                  • 0

                    Может. На zfs cow с чексамингом. Это две совсем разных технологии.

                    • 0

                      Я правильно понимаю что с zfs не работали но в целом осуждает)?

                      • +2

                        Я просто обращаю ваше внимание, что, во-первых, сама методика тестирования вызвает вопросы, во-вторых, при получении явно неадекватного результата вы не хотите задуматься о его причинах и произвести настройку системы в соответствии с задачами, которые собираетесь на ней решать. А поскольку работать с этим вам, а не мне, я ничего не осуждаю. :)

                        • –1

                          Ну и стоило ли тогда?)

                • +1
                  Я правильно понимаю, что вы тестируете 4k блоками ZFS с дефолтным recordsize=128k? В начале статьи упомянуты виртуальные машины, но не упомянуты методы виртуализации, и как диски машин хранятся на файловой системе. Без оглядки на виртуализацию (внутри виртуалок обычно работают реальные задачи) для MySQL/InnoDB размер recordsize должен равнятся 16k (по умолчанию), для PostgreSQL — 8k. Если у вас предполагаемая нагрузка не БД, а отдача файлов, то тестировать надо вообще блоками по 128k.
                  Ну и ARC для zfs выключается zfs set primarycache=metadata, если нужно оценить его влияние на скорость чтения. Ну и 10Гб — весьма странный объем данных для тестирования, сейчас памяти в серверах в разы больше, для устранения влияния кэшей размер должен быть больше объема памяти на порядок.
                  • –1
                    Вы не много путаете ashift и recordsize
                    В моем случае я создаю ashift=12 (4096B блок)
                    • +1
                      Вы точно уверены, что я путаю? ashift имеет отношение к таблице разделов, и это выравнивание первого блока в файловой системе, чтобы он не пересекал границы блоков физических устройств. И последние года 4 использование неправильного ashift не дает негативного эффекта, по причине особой умности современных SSD. А recordsize — это размер блока, которым производится запись и чтение. Если вы читаете/пишете 4к рандомно, то вы читаете/пишете с диска 128к (не считая неполных блоков). Этим и объясняется разница в результатах write и randwrite (где нет никаого ARC)
                      • 0
                        Отлично, но это не отменяет результата тестирования)

                        «Традиционно тест идёт с размером блока в 4к. Почему? Потому что это стандартный размер блока, которым оперируют ОС при сохранении файла. Это размер страницы памяти и вообще, Очень Круглое Компьютерное Число.
                        Нужно понимать, что если система обрабатывает 100 IOPS с 4к блоком (worst), то она будет обрабатывать меньше при 8к блоке (не менее 50 IOPS, вероятнее всего, в районе 70-80). Ну и на 1Мб блоке мы увидим совсем другие цифры»
                        habrahabr.ru/post/154235
                        • +2
                          Тут надо заметить, что то, с каким размером блока оперирует файловая система, не означает, что приложение внутри нее делают рандомную запись и чтение такими блоками. Исходя из вашей информации, у вас вероятно полная виртуализация (не контейнерная), из чего следует, что команды чтения передаются виртуальному блочному устройству, в случае с какой-нить WinXP — виртуальному SATA контроллеру. Действительно, ОС будет выдавать команды на чтение и запись по 4кб, но это не означает, что это эквивалент 4k randread/randwrite. Я выше писал, какими блоками оперируют базы данных, это означает, что в случае 8k блока, ОС передаcт команды на чтение 2х последовательных 4k блоков.

                          Вообще, для такого случая использовать ZFS и хранящийся на ней файл — серьезный оверхед, потому как там для консистентности используется двойная запись (ZIL), для выравнивания надо было сделать zfs set sync=disabled

                          Но на самом деле, разговор совсем не о том. А о том, что вы тестировали 4k randread/randwrite фактически на устройстве с 128k блоком, в сравнении с 4k ext4, а вопрос был уже задан выше — что вы намеряли?
                          • +1
                            Кстати, пропустил интересный аргумент. Это же SSD, у которого нет разницы в randwrite и sequential write. У вас в последнем тесте IOPS на ext4 в write и randwrite одинаковы, так с чего бы вдруг такая разница у ZFS? Кэши на запись?
                            • 0

                              По спецификации нет разницы между линейным и случайным?
                              Виртуализация lxc поверх raw образа

                              • 0
                                Строго говоря у SSD есть разница между рандомной и последовательной записью из-за продвинутости контроллера, сжатия и пр. Но она крайне незначительна, что видно на вашем тесте ext4 single для write и randwrite.
                                • 0
                                  Трудно сказать в чем природа такой разницы в данном случае, наверное стоило бы изучить эту проблему подробней. Но на мой взгляд, результаты отражают реальное положение дел. Те если нет задачи глубоко изучить вопрос, а лишь принять решение то данных достаточно для его принятия
                            • 0

                              А мне надо было ext4 тестировать с 128k блоком? Или разные параметры при тестировании указывать?

                              • +1
                                Очевидно, выставить recordsize=4k до начала тестирования
                                • 0
                                  Ну в смысле чисто ради теста? тест ради теста? если оно по умолчанию стоит так то я буду тестировать его так как оно по умолчанию) я же не попрошу приложения писать исключительно блоком 128k?
                                  • +1
                                    Совсем не ради теста. размер блока ФС виртуалки, должен быть равен recordsize на ZFS. иначе получаете фигню. Ведь вы почему то применили ashift=12 для ZFS, чтобы не загубить производительность.
                                    файл виртуальной машины для этой самой виртуалки такое же устройство как диск для ZFS. Так почему же Вы не забили на размер блока когда размещали ZFS на SSD (т.е. изменили дефолтный ashift), а когда разместили файл виртуальной машины на ZFS, то забили на дефолтный recodrsize (128K)?
                                    • 0
                                      Согласен, нужно перепроверить!
                      • 0
                        В моем кейсе, виртуальные машины хранятся в raw файлах
                        • 0
                          Разумеется пробовал zfs set primarycache=metadata и zfs set primarycache=off
                          Но в данном случае, мне кажется что дизайн самой файловой системы таков, что кеш должен быть включен что бы она могла обеспечивать нормальную работу. Кроме того, мы тестируем реальные задачи. В реальных задачах я бы выключать кеш не стал был.
                          С другой стороны, на стороне mdadm так же есть своя буферизация, которую я выключить не могу.
                        • +1
                          Яркий пример, как не надо делать тесты

                          1. Взяли дохлый контроллер, который не может в полную скорость даже одного диска.
                          2. Взяли миниатюрный файл, который оседает в кеше.
                          3. где xfs?

                          Результат в итоге плачевный.
                          • 0
                            Взяли дохлый контроллер

                            Там IT mode, в режиме HBA он 4 указанных диска вполне должен прожевать (хотя и близко к пределу).

                            • +1
                              Официально да, должен. Но это самый дешевый «raid» контроллер для серверов нынче. И в реальности он выше sata2 скоростей не тянет (в смысле постоянно, без всяких бурстов). Даже если во все 8 дырок включить ssd — выше гигабайта с него не снимается. Да и «тесты» подтверждают — там где один диск на ext4: ssd на 400+ выдает почему-то ~200.
                              • 0

                                Причем контроллер. Он один и тот же для всех испытуемых, те даже если он не даст максимум, если, то разницу покажет

                                • +1
                                  Проблема в том, что у этого контроллера очень (подчеркиваю, очень) слабый проц. И он к примеру, дохнет на несимметричной загрузке (когда например 3 читают, а один пишет) по каналам.
                                • 0

                                  Потому что в 32 потока. В 1 поток линейно быстрее.

                                  • 0
                                    Возьмите любой тест ssd и посмотрите. Привычные для всяких сайтов типа оверклокера 64 потока на случайном чтении дают пенальти против последовательного — примерно в 30 процентов. 32 должны давать еще меньше.

                                    У вас — больше 50.
                            • 0
                              Слава, если ты не в курсе, но xfs медленнее ext4 примерно на 10%. В официальных гайдах деплоя MySQL рекомендуют базу класть на ext4.
                              • 0
                                Ну у меня другие данные. Но именно на этом «тесте» (мелкие файлы, куча памяти) можно было получить очень интересные результаты.
                                • 0
                                  Интересно. А где можно посмотреть твои данные?
                              • 0

                                Причем тут xfs
                                Контроллер в it mode. Те hba.
                                При тестировании direct=1 buffered=0
                                Причем тут кеш? Не дочитали?

                                • +1
                                  При том, что xfs, как и mdadm имеют свой «кеш» и плюют на эти опции.
                                  • 0

                                    Хорошо) мы выяснили что у ext4+mdadm кеш быстрее) ровно то что и хотели выяснить

                              • 0
                                Уже 2 недели пытаюсь получить внятные цифры по тестам производительности ZFS.

                                Пробовал отключать primary/secondary cache. При отключенных кэшах рандомная запись в файл на датасет с recordsize 4k получается 200МБ/с и 50к+ IOPS. На датасеты с recordsize 8k и 128k и отключенном кэше получаются внятные результаты, рандомная запись — 800-1000КБ/с и 150-170 IOPS. При включенном кэше датасеты с recordsize 8k и 128k рандомная запись выше, но не сильно, явно ниже показателей датасета с recordsize 4k.
                                ZVOL похоже вообще игнорирует настройки кэшей, так как независимо от настройки кэшей выдаёт одинаковые результаты — 100МБ/с и 23-24к IOPS. Пробовал volblocksize 4k и 8k. На 8k похуже запись, получше чтение, но цифры всё равно гигантские.

                                Тестирую fio на хосте ZFS и в виртуальной машине, размер диска/файла — 20гб. Размер блока — 4КБ.
                                Виртуализация KVM. Режим кэша диска виртуальной машины = none.
                                Размер ARC ограничен 4ГБ. Sync=standart. Ashift=9. Xattrs=on. Compression=off.
                                Размер сектора диска=512б, обычные SATA 7200RPM.

                                Может кто-нибудь дать рекомендации как тестировать ZFS? Я не понимаю откуда берутся такие цифры.

                                Спасибо.
                                • +1
                                  1. Проверить поддержку Advanced Format — 4k блоки вместо 512b: smartctl -i /dev/sd[a-z] | grep 'Sector Size'. Если 4k — то это будет оптимальный вариант.
                                  2. Я бы не ожидал космических скоростей от SATA дисков
                                  3. Никогда не ставьте ZFS поверх LVM — cow+cow =ultra slow
                                  4. Для kvm рекомендуют (proxmox) устанавливать volblocksize 8k. Но это зависит от нагрузок внутри ВМ. Можно и 32k ставить, если много операций записи.
                                  5. ashift = 12 обязательно, compression = lz4 желательно.
                                  6. Если сервер подключен к UPS + выпрямитель + usb/com-кабель + apsupsd, то можно попробовать sync = disabled.

                                  Вообще, никого не должно удивлять, что ZFS медленнее ext4/xfs. Т.к. ZFS использует прослойку-эмулятор от Solaris (spl), свой кеш, управление памятью.
                                  Плюс checksum, свой встроенный "lvm", "mdadm".
                                  Нужно быть к этому готовым.

                                • +1
                                  При использовании ZFS датастора в сценарии хранилища под виртуалки, нужно ещё префетч отключать, так как он профита никакого не даёт, но подгребает под себя IOPSы. Отключение префетча добавляет в синтетических тестах около 20% производительности.

                                  В конце поста вы почему-то говорите про ZIL, и упоминаете «буфер 50 Гб». ZIL тут ни при чём, он используется только в сценарии с синхронной записью. При асинхронной лог не пишется, и ZIL не задействуется. ARC — да, работает всегда. Правда, непонятно, почему вы решили зажать ARC на четверть объёма оперативы. Если у вас это чистая хранилка, то отдайте ему всё, что он сможет забрать.

                                  Далее, судя по параметру --runtime=60 в тестах, вы запускали тесты всего на 60 секунд. Ясное дело, что никакие кэши тут не помогут — они просто прогреться не успевают.

                                  И компрессию на ZFS вы выключили совершенно напрасно. Сжатие снижает число реальных ИОПСов, долетающих до дисков.
                                  • 0
                                    Префетч выключен по умолчанию в последних версиях zfsonlinux.
                                    По тексту опечатка про ZIL, спасибо
                                  • +2
                                    1. Вы не правильно установили размер блока для ssd.

                                    Вот тут есть правильная таблица размеров блока:
                                    github.com/zfsonlinux/zfs/blob/ea39f75f64ff72e30900a36e00632f180f5f6676/cmd/zpool/zpool_vdev.c#L102

                                    Как видно из таблицы, большинство современных SSD имеют размер блока 8192.

                                    2. Также вы напрасно игнорируете пропускную способность контроллера.
                                    Вот хорошая статья про это:
                                    www.truesystem.ru/solutions/khranenie_danny/361566
                                    Обратите внимание на максимальное количество iops, которое можно получить с вашего бюджетного контроллера.

                                    3. Также стоит отключать prefetch для zfs.
                                    options zfs zfs_prefetch_disable=1
                                    Иначе вы дополнительно читаете с SSD, что в тесте на случайное чтение даёт худший результат.

                                    4. recordsize.
                                    По нашим тестам для SSD лучше всего использовать размер в 64K.

                                    5. Раз вы используете zfsonlinux, было бы прекрасно после тестов приложить вывод следующих команд:
                                    zpool iostat -w
                                    zpool iostat -r
                                    arc_summary.py
                                    Сделать это после проведения каждого теста. Каждый тест начинать после полного ребута машины.
                                    • 0
                                      1 Предварительно проверил
                                      smartctl -a /dev/sdb | grep 'Sector Size'
                                      Sector Sizes: 512 bytes logical, 4096 bytes physical

                                      2 Может быть я не получил максимальные показатели но имею возможность сравнить разницу

                                      3 Это давно выключено по умолчанию в zfsonlinux
                                  • +1
                                    Во-первых, спасибо за проделанную работу! Я теперь хотя бы знаю как в линуксе можно тестировать файловые системы!
                                    Во-вторых, прошу вас напишите, что ZFS хоть и медленная при записи (быстрая при чтении), но обладает огромным преимуществом перед классическими файловыми системами. Механизмом снимков и COW дизайном.

                                    Собственно из-за некоторых из преимуществ у нее такая медленная запись, т.к. она имеет транзакционную природу и запись производится в несколько этапов. Для особых случаев, где важна и скорость и надежность данных, можно добавить Intel Optane в пул ZFS, в качестве Log устройства.

                                    То есть я хочу сказать, что скорость не всегда главное и вы можете отпугнуть людей. Часто ZFS работает «достаточно» быстро и в этом случае не вижу причин ее не использовать.

                                    Сравнение было бы более корректно с любой другой COW файловой системой со встроенными снимками или с LVM + рэйд

                                    Снимки и надежность очень важны!
                                    • 0

                                      Извините, так вы что тестируете, работу с файлами, или гипервизор? Для бенчмарка гипервизора (к примеру, на kvm) нужен совсем другой подход, где как раз mdadm + ext4 даст просадку.


                                      Многие комментаторы выше уже указали на явные вопросы в тесте.


                                      Касаемо zfs — вы собрали большинство worst practices:


                                      • проигнорирован recordsize (что больше всего проблем вам и даёт)
                                      • тестируется dataset, когда в гипервизоре будет применяться vdev
                                      • забыли о xattr=sa (иначе на каждую операцию с метаданными на линуксе вы прибавляете по несколько io)
                                      • не оптимальный ashift
                                      • raid контроллер (даже в режиме it mode это не лучший вариант), тем более для ssd
                                      • игнорируете cow природу zfs, на гипервизоре её возможности вам очень понадобятся, при использовании снапшотов ощутите отсутствие нагрузки, которая раньше была при создании бекапов

                                      Не всё так однозначно. Естественно, что zfs будет медленнее на многих кейсах, но у неё куча killer фич, а в некоторых случаях (к примеру, случайная запись — превращается в последовательную) она всегда будет рвать другие ФС.


                                      У каждой ФС своё применение, не судите так однозначно.


                                      Если вам интересно — я полгода назад писал статью о zfs и её подводных камнях https://m.habrahabr.ru/post/314506/, состою в проекте ZFSonLinux. Жалко видеть разочарование от труда многих людей, когда вы разбираются в причинах таких результатов.

                                      • 0
                                        Я ни слова ни написал что ZFS это плохо или хорошо)

                                        проигнорирован recordsize (что больше всего проблем вам и даёт)
                                        согласен, наверное.

                                        тестируется dataset, когда в гипервизоре будет применяться vdev

                                        Как я писал выше, виртуальный машины лежат в raw файлах поверх ext4

                                        забыли о xattr=sa (иначе на каждую операцию с метаданными на линуксе вы прибавляете по несколько io)

                                        тут не могу прокомментировать

                                        не оптимальный ashift

                                        почему? какой оптимальный и почему?

                                        raid контроллер (даже в режиме it mode это не лучший вариант), тем более для ssd
                                        почему?

                                        игнорируете cow природу zfs, на гипервизоре её возможности вам очень понадобятся, при использовании снапшотов ощутите отсутствие нагрузки, которая раньше была при создании бекапов

                                        почему вы решили что я это игнорирую?
                                        • +1
                                          Как я писал выше, виртуальный машины лежат в raw файлах поверх ext4

                                          Извиняюсь, опечатался, не vdev а volume. Для zfs это бессмысленно, у него для этих целей есть volume, proxmox их поддерживает. Моё личное мнение — тестировать надо весь стек, включая виртуализацию, то есть ставить vm с драйверами и внутри гонять fio. Для raw файла должны быть дополнительные накладные расходы.

                                          почему? какой оптимальный и почему?

                                          Выше уже давали ссылку на размеры ashift для ssd, чаще всего они 8к и более. Также бывает, что быстрее работает 512б (особенности конкретного ssd).

                                          По raid контроллеру всё просто — даже в режиме it mode он работает через свой ограниченный процессор, тогда как настоящий hba контроллер намного эффективнее. Вот вам ссылка со списком по скоростям blog.zorinaq.com/from-32-to-2-ports-ideal-satasas-controllers-for-zfs-linux-md-ra

                                          почему вы решили что я это игнорирую?

                                          Потому что в конце статьи ваше решение о выборе исходит только из полученных вами цифр (перечитал, всё равно складывается именно такое ощущение), не упоминаются ни контрольные суммы, ни снапшоты. Именно снапшоты дадут вам выигрыш во многих моментах с виртуализацией.

                                          Также про сравнение «zraid/2 или 0+1» — у raidz будет всегда хуже iops, везде об этом говорится (подтверждаю личным опытом), raidz ограничен iops самого медленного диска в массиве. То есть raid 10 из 4 дисков должен быть при правильных настройках быстрее по iops, чем raidz1 на этих же дисках. Ваши цифры говорят именно о проблемах с настройкой zfs.
                                      • 0
                                        Неплохо было бы еще к тесту добавить btrfs

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

                                        Самое читаемое