Pull to refresh

Comments 65

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

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

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

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

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


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


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

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

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

Вашего оборудования. 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 файл мне не кажется разумным приближением к задаче.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уже 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. Проверить поддержку 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".
Нужно быть к этому готовым.

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

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

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

И компрессию на ZFS вы выключили совершенно напрасно. Сжатие снижает число реальных ИОПСов, долетающих до дисков.
Префетч выключен по умолчанию в последних версиях zfsonlinux.
По тексту опечатка про ZIL, спасибо
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
Сделать это после проведения каждого теста. Каждый тест начинать после полного ребута машины.
1 Предварительно проверил
smartctl -a /dev/sdb | grep 'Sector Size'
Sector Sizes: 512 bytes logical, 4096 bytes physical

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

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

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

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

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

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

Извините, так вы что тестируете, работу с файлами, или гипервизор? Для бенчмарка гипервизора (к примеру, на 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. Жалко видеть разочарование от труда многих людей, когда вы разбираются в причинах таких результатов.

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

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

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

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

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

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

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

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

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

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

почему вы решили что я это игнорирую?
Как я писал выше, виртуальный машины лежат в 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.
Неплохо было бы еще к тесту добавить btrfs
Only those users with full accounts are able to leave comments. Log in, please.