Comments 65
Классический Raid на SSD не самое удачное решение. Для Raid 5/6 ещё куда ни шло, хотя уже существуют более удачные для SSD варианты: разнообразные "матричные" решения в проприетарных сторожах. А вот RAID10 выглядит очень плохим вариантом из-за низкой надежности. Дело в том, что HDD умерали по механическим причинам и даже при равномерной нагрузке поломки проиходили в разное время. А вот SSD умирает по счетчику и при равномерной нагрузке очень велика вероятность близкого к одновременному выходу из строя.
Пока не видел.
Вроде тут какой-то крупный хостер говорил, что они тупо ставят чипы разного производителя в зеркало.
* А то ходят легенды, что еще ни один новый SSD не умер по причине исчерпания ресурса перезаписи в ячейках (ну, возможно, с учетом резервных ячеек).
Полного исчерпания не было, но вот несколько SSD со скоростью работы USB-флешки я наблюдал. гораздо больше их попередохло из-за выхода из строя контроллеров.
Мы будем проводить тест с файлом размером в 10ГБ. Предположительно, что этого размера достаточно, чтобы оценить производительность файловой системы при выполнении рутинных операций. Разумеется, если увеличить объем тестовых данных, то общие цифры по всем тестам будут значительно ниже, так как мы сведем на нет все дополнительные средства кеширования и предсказания на файловых системах.
Иными словами, померяли непонятно что. :)
Во-первых, если вы пытаетесь оценить "реальную работу гипервизора", то это даже близко не сценарий "10Гб горячих данных в одном файле". Данные, как минимум, разнесены по разным файлам, что должно существенно влиять на поведение файловой системы при кэшировании. Хотите тестировать именно такой паттерн нагрузки — для этого есть специальные тесты, а пытаться эмулировать его таким образом — заведомо получать результаты, которые с реальностью будут коррелировать не пойми как.
Во-вторых, нет даже попытки анализа (хотя бы загрузки процессора и потребление памяти дополнительно). 2K иопс на запись, серьезно? И во что упираемся? По мне так похоже на какие-то проблемы с конфигурацией. При этом у вас на ext4 на запись 43К iops, что втрое превосходит официальный максимум по спекам производителя ("до 14K"). Это на фоне того, что по случайном чтению вы до них, наоборот, серьезно недотягиваете. Вопрос "что намеряли" возникает сам собой.
Что касается загрузки ЦПУ и расхода памяти, то на данной конфигурации они были минимальны и я ими пренебрёг так как это не играет для меня существенной роли.
Какие официальные спеки? Какие проблемы с конфигурацией? Какие специальные тесты?
Был бы благодарен за большее количество конкретики.
Какие официальные спеки?
Вашего оборудования. 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 не работали но в целом осуждает)?
Я просто обращаю ваше внимание, что, во-первых, сама методика тестирования вызвает вопросы, во-вторых, при получении явно неадекватного результата вы не хотите задуматься о его причинах и произвести настройку системы в соответствии с задачами, которые собираетесь на ней решать. А поскольку работать с этим вам, а не мне, я ничего не осуждаю. :)
Ну и ARC для zfs выключается zfs set primarycache=metadata, если нужно оценить его влияние на скорость чтения. Ну и 10Гб — весьма странный объем данных для тестирования, сейчас памяти в серверах в разы больше, для устранения влияния кэшей размер должен быть больше объема памяти на порядок.
В моем случае я создаю ashift=12 (4096B блок)
«Традиционно тест идёт с размером блока в 4к. Почему? Потому что это стандартный размер блока, которым оперируют ОС при сохранении файла. Это размер страницы памяти и вообще, Очень Круглое Компьютерное Число.
Нужно понимать, что если система обрабатывает 100 IOPS с 4к блоком (worst), то она будет обрабатывать меньше при 8к блоке (не менее 50 IOPS, вероятнее всего, в районе 70-80). Ну и на 1Мб блоке мы увидим совсем другие цифры»
habrahabr.ru/post/154235
Вообще, для такого случая использовать ZFS и хранящийся на ней файл — серьезный оверхед, потому как там для консистентности используется двойная запись (ZIL), для выравнивания надо было сделать zfs set sync=disabled
Но на самом деле, разговор совсем не о том. А о том, что вы тестировали 4k randread/randwrite фактически на устройстве с 128k блоком, в сравнении с 4k ext4, а вопрос был уже задан выше — что вы намеряли?
По спецификации нет разницы между линейным и случайным?
Виртуализация lxc поверх raw образа
А мне надо было ext4 тестировать с 128k блоком? Или разные параметры при тестировании указывать?
файл виртуальной машины для этой самой виртуалки такое же устройство как диск для ZFS. Так почему же Вы не забили на размер блока когда размещали ZFS на SSD (т.е. изменили дефолтный ashift), а когда разместили файл виртуальной машины на ZFS, то забили на дефолтный recodrsize (128K)?
Но в данном случае, мне кажется что дизайн самой файловой системы таков, что кеш должен быть включен что бы она могла обеспечивать нормальную работу. Кроме того, мы тестируем реальные задачи. В реальных задачах я бы выключать кеш не стал был.
С другой стороны, на стороне mdadm так же есть своя буферизация, которую я выключить не могу.
1. Взяли дохлый контроллер, который не может в полную скорость даже одного диска.
2. Взяли миниатюрный файл, который оседает в кеше.
3. где xfs?
Результат в итоге плачевный.
Взяли дохлый контроллер
Там IT mode, в режиме HBA он 4 указанных диска вполне должен прожевать (хотя и близко к пределу).
Причем тут xfs
Контроллер в it mode. Те hba.
При тестировании direct=1 buffered=0
Причем тут кеш? Не дочитали?
Пробовал отключать 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? Я не понимаю откуда берутся такие цифры.
Спасибо.
- Проверить поддержку Advanced Format — 4k блоки вместо 512b: smartctl -i /dev/sd[a-z] | grep 'Sector Size'. Если 4k — то это будет оптимальный вариант.
- Я бы не ожидал космических скоростей от SATA дисков
- Никогда не ставьте ZFS поверх LVM — cow+cow =ultra slow
- Для kvm рекомендуют (proxmox) устанавливать volblocksize 8k. Но это зависит от нагрузок внутри ВМ. Можно и 32k ставить, если много операций записи.
- ashift = 12 обязательно, compression = lz4 желательно.
- Если сервер подключен к UPS + выпрямитель + usb/com-кабель + apsupsd, то можно попробовать sync = disabled.
Вообще, никого не должно удивлять, что ZFS медленнее ext4/xfs. Т.к. ZFS использует прослойку-эмулятор от Solaris (spl), свой кеш, управление памятью.
Плюс checksum, свой встроенный "lvm", "mdadm".
Нужно быть к этому готовым.
В конце поста вы почему-то говорите про ZIL, и упоминаете «буфер 50 Гб». ZIL тут ни при чём, он используется только в сценарии с синхронной записью. При асинхронной лог не пишется, и ZIL не задействуется. ARC — да, работает всегда. Правда, непонятно, почему вы решили зажать ARC на четверть объёма оперативы. Если у вас это чистая хранилка, то отдайте ему всё, что он сможет забрать.
Далее, судя по параметру --runtime=60 в тестах, вы запускали тесты всего на 60 секунд. Ясное дело, что никакие кэши тут не помогут — они просто прогреться не успевают.
И компрессию на ZFS вы выключили совершенно напрасно. Сжатие снижает число реальных ИОПСов, долетающих до дисков.
Вот тут есть правильная таблица размеров блока:
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
Сделать это после проведения каждого теста. Каждый тест начинать после полного ребута машины.
smartctl -a /dev/sdb | grep 'Sector Size'
Sector Sizes: 512 bytes logical, 4096 bytes physical
2 Может быть я не получил максимальные показатели но имею возможность сравнить разницу
3 Это давно выключено по умолчанию в zfsonlinux
Наш опыт показывает что так явно будет быстрее.
А также опыт коллективного разума говорит о том же.
www.reddit.com/r/zfs/comments/3tyyj7/why_doesnt_recordsize_default_to_blocksize
3) по умолчанию prefetch включён https://github.com/zfsonlinux/zfs/blob/master/man/man5/zfs-module-parameters.5#L1625
Во-вторых, прошу вас напишите, что 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. Жалко видеть разочарование от труда многих людей, когда вы разбираются в причинах таких результатов.
проигнорирован 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.
Производительность mdadm raid 5,6,10 и ZFS zraid, zraid2, ZFS striped mirror