для выбора технологии создания локального дискового массива.
Цель данного тестирования — выяснить, с какой реальной скоростью смогут работать виртуальные машины в raw файловых образах, если разместить их на 4-х производительных SSD-дисках. Тестирование будет производится в 32 потока, чтобы приблизительно создать условия работы реального гипервизора.
- Zabbix 2.2 верхом на nginx + php-fpm и mariadb
- HAPRoxy для Percona или Galera на CentOS. Его настройка и мониторинг в Zabbix
- «Идеальный» www-кластер. Часть 1. Frontend: NGINX + Keepalived (vrrp) на CentOS
- «Идеальный» кластер. Часть 2.1: Виртуальный кластер на hetzner
- «Идеальный» кластер. Часть 2.2: Высокодоступный и масштабируемый web-сервер, лучшие технологии на страже вашего бизнеса
- «Идеальный» кластер. Часть 3.1 Внедрение MySQL Multi-Master кластера
- Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP
- Сравнение скорости исполнения кода Drupal для PHP 5.3-5.6 и 7.0. «Битва оптимизаторов кода» apc vs xcache vs opcache
- Производительность Bitrix Старт на Proxmox и Virtuozzo 7 & Virtuozzo Storage
- Virtuozzo Storage: Реальный опыт эксплуатации, советы по оптимизации и решению проблем
Замеры будем производить при помощи инструмента 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)
ildarz
08.12.2017 12:51-1Мы будем проводить тест с файлом размером в 10ГБ. Предположительно, что этого размера достаточно, чтобы оценить производительность файловой системы при выполнении рутинных операций. Разумеется, если увеличить объем тестовых данных, то общие цифры по всем тестам будут значительно ниже, так как мы сведем на нет все дополнительные средства кеширования и предсказания на файловых системах.
Иными словами, померяли непонятно что. :)
Во-первых, если вы пытаетесь оценить "реальную работу гипервизора", то это даже близко не сценарий "10Гб горячих данных в одном файле". Данные, как минимум, разнесены по разным файлам, что должно существенно влиять на поведение файловой системы при кэшировании. Хотите тестировать именно такой паттерн нагрузки — для этого есть специальные тесты, а пытаться эмулировать его таким образом — заведомо получать результаты, которые с реальностью будут коррелировать не пойми как.
Во-вторых, нет даже попытки анализа (хотя бы загрузки процессора и потребление памяти дополнительно). 2K иопс на запись, серьезно? И во что упираемся? По мне так похоже на какие-то проблемы с конфигурацией. При этом у вас на ext4 на запись 43К iops, что втрое превосходит официальный максимум по спекам производителя ("до 14K"). Это на фоне того, что по случайном чтению вы до них, наоборот, серьезно недотягиваете. Вопрос "что намеряли" возникает сам собой.
SyCraft Автор
08.12.2017 12:57Как раз это вполне реальная ситуация. Когда в 1 raw файл образа диска идет некоторое количество одновременных потоков. В нашем случае 32.
Что касается загрузки ЦПУ и расхода памяти, то на данной конфигурации они были минимальны и я ими пренебрёг так как это не играет для меня существенной роли.
Какие официальные спеки? Какие проблемы с конфигурацией? Какие специальные тесты?
Был бы благодарен за большее количество конкретики.ildarz
08.12.2017 14:21Какие официальные спеки?
Вашего оборудования. 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 файл мне не кажется разумным приближением к задаче.
SyCraft Автор
08.12.2017 15:14Я правильно понимаю что с zfs не работали но в целом осуждает)?
ildarz
08.12.2017 15:31Я просто обращаю ваше внимание, что, во-первых, сама методика тестирования вызвает вопросы, во-вторых, при получении явно неадекватного результата вы не хотите задуматься о его причинах и произвести настройку системы в соответствии с задачами, которые собираетесь на ней решать. А поскольку работать с этим вам, а не мне, я ничего не осуждаю. :)
BasilioCat
08.12.2017 13:03Я правильно понимаю, что вы тестируете 4k блоками ZFS с дефолтным recordsize=128k? В начале статьи упомянуты виртуальные машины, но не упомянуты методы виртуализации, и как диски машин хранятся на файловой системе. Без оглядки на виртуализацию (внутри виртуалок обычно работают реальные задачи) для MySQL/InnoDB размер recordsize должен равнятся 16k (по умолчанию), для PostgreSQL — 8k. Если у вас предполагаемая нагрузка не БД, а отдача файлов, то тестировать надо вообще блоками по 128k.
Ну и ARC для zfs выключается zfs set primarycache=metadata, если нужно оценить его влияние на скорость чтения. Ну и 10Гб — весьма странный объем данных для тестирования, сейчас памяти в серверах в разы больше, для устранения влияния кэшей размер должен быть больше объема памяти на порядок.SyCraft Автор
08.12.2017 13:08Вы не много путаете ashift и recordsize
В моем случае я создаю ashift=12 (4096B блок)BasilioCat
08.12.2017 13:18Вы точно уверены, что я путаю? ashift имеет отношение к таблице разделов, и это выравнивание первого блока в файловой системе, чтобы он не пересекал границы блоков физических устройств. И последние года 4 использование неправильного ashift не дает негативного эффекта, по причине особой умности современных SSD. А recordsize — это размер блока, которым производится запись и чтение. Если вы читаете/пишете 4к рандомно, то вы читаете/пишете с диска 128к (не считая неполных блоков). Этим и объясняется разница в результатах write и randwrite (где нет никаого ARC)
SyCraft Автор
08.12.2017 13:21Отлично, но это не отменяет результата тестирования)
«Традиционно тест идёт с размером блока в 4к. Почему? Потому что это стандартный размер блока, которым оперируют ОС при сохранении файла. Это размер страницы памяти и вообще, Очень Круглое Компьютерное Число.
Нужно понимать, что если система обрабатывает 100 IOPS с 4к блоком (worst), то она будет обрабатывать меньше при 8к блоке (не менее 50 IOPS, вероятнее всего, в районе 70-80). Ну и на 1Мб блоке мы увидим совсем другие цифры»
habrahabr.ru/post/154235BasilioCat
08.12.2017 15:20Тут надо заметить, что то, с каким размером блока оперирует файловая система, не означает, что приложение внутри нее делают рандомную запись и чтение такими блоками. Исходя из вашей информации, у вас вероятно полная виртуализация (не контейнерная), из чего следует, что команды чтения передаются виртуальному блочному устройству, в случае с какой-нить WinXP — виртуальному SATA контроллеру. Действительно, ОС будет выдавать команды на чтение и запись по 4кб, но это не означает, что это эквивалент 4k randread/randwrite. Я выше писал, какими блоками оперируют базы данных, это означает, что в случае 8k блока, ОС передаcт команды на чтение 2х последовательных 4k блоков.
Вообще, для такого случая использовать ZFS и хранящийся на ней файл — серьезный оверхед, потому как там для консистентности используется двойная запись (ZIL), для выравнивания надо было сделать zfs set sync=disabled
Но на самом деле, разговор совсем не о том. А о том, что вы тестировали 4k randread/randwrite фактически на устройстве с 128k блоком, в сравнении с 4k ext4, а вопрос был уже задан выше — что вы намеряли?BasilioCat
08.12.2017 15:30Кстати, пропустил интересный аргумент. Это же SSD, у которого нет разницы в randwrite и sequential write. У вас в последнем тесте IOPS на ext4 в write и randwrite одинаковы, так с чего бы вдруг такая разница у ZFS? Кэши на запись?
SyCraft Автор
08.12.2017 15:40По спецификации нет разницы между линейным и случайным?
Виртуализация lxc поверх raw образаBasilioCat
08.12.2017 16:14Строго говоря у SSD есть разница между рандомной и последовательной записью из-за продвинутости контроллера, сжатия и пр. Но она крайне незначительна, что видно на вашем тесте ext4 single для write и randwrite.
SyCraft Автор
08.12.2017 18:03Трудно сказать в чем природа такой разницы в данном случае, наверное стоило бы изучить эту проблему подробней. Но на мой взгляд, результаты отражают реальное положение дел. Те если нет задачи глубоко изучить вопрос, а лишь принять решение то данных достаточно для его принятия
SyCraft Автор
08.12.2017 15:44А мне надо было ext4 тестировать с 128k блоком? Или разные параметры при тестировании указывать?
BasilioCat
08.12.2017 16:55Очевидно, выставить recordsize=4k до начала тестирования
SyCraft Автор
08.12.2017 18:01Ну в смысле чисто ради теста? тест ради теста? если оно по умолчанию стоит так то я буду тестировать его так как оно по умолчанию) я же не попрошу приложения писать исключительно блоком 128k?
RomanStrlcpy
08.12.2017 21:28Совсем не ради теста. размер блока ФС виртуалки, должен быть равен recordsize на ZFS. иначе получаете фигню. Ведь вы почему то применили ashift=12 для ZFS, чтобы не загубить производительность.
файл виртуальной машины для этой самой виртуалки такое же устройство как диск для ZFS. Так почему же Вы не забили на размер блока когда размещали ZFS на SSD (т.е. изменили дефолтный ashift), а когда разместили файл виртуальной машины на ZFS, то забили на дефолтный recodrsize (128K)?
SyCraft Автор
08.12.2017 13:12Разумеется пробовал zfs set primarycache=metadata и zfs set primarycache=off
Но в данном случае, мне кажется что дизайн самой файловой системы таков, что кеш должен быть включен что бы она могла обеспечивать нормальную работу. Кроме того, мы тестируем реальные задачи. В реальных задачах я бы выключать кеш не стал был.
С другой стороны, на стороне mdadm так же есть своя буферизация, которую я выключить не могу.
kiltum
08.12.2017 14:25Яркий пример, как не надо делать тесты
1. Взяли дохлый контроллер, который не может в полную скорость даже одного диска.
2. Взяли миниатюрный файл, который оседает в кеше.
3. где xfs?
Результат в итоге плачевный.ildarz
08.12.2017 14:45Взяли дохлый контроллер
Там IT mode, в режиме HBA он 4 указанных диска вполне должен прожевать (хотя и близко к пределу).
kiltum
08.12.2017 14:56Официально да, должен. Но это самый дешевый «raid» контроллер для серверов нынче. И в реальности он выше sata2 скоростей не тянет (в смысле постоянно, без всяких бурстов). Даже если во все 8 дырок включить ssd — выше гигабайта с него не снимается. Да и «тесты» подтверждают — там где один диск на ext4: ssd на 400+ выдает почему-то ~200.
SyCraft Автор
08.12.2017 15:13Причем контроллер. Он один и тот же для всех испытуемых, те даже если он не даст максимум, если, то разницу покажет
kiltum
08.12.2017 15:28Проблема в том, что у этого контроллера очень (подчеркиваю, очень) слабый проц. И он к примеру, дохнет на несимметричной загрузке (когда например 3 читают, а один пишет) по каналам.
evilbot
08.12.2017 15:02Слава, если ты не в курсе, но xfs медленнее ext4 примерно на 10%. В официальных гайдах деплоя MySQL рекомендуют базу класть на ext4.
SyCraft Автор
08.12.2017 15:12Причем тут xfs
Контроллер в it mode. Те hba.
При тестировании direct=1 buffered=0
Причем тут кеш? Не дочитали?
Bargheld
08.12.2017 18:14Уже 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? Я не понимаю откуда берутся такие цифры.
Спасибо.
SergeyD
09.12.2017 21:50- Проверить поддержку 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".
Нужно быть к этому готовым.
athacker
08.12.2017 19:02При использовании ZFS датастора в сценарии хранилища под виртуалки, нужно ещё префетч отключать, так как он профита никакого не даёт, но подгребает под себя IOPSы. Отключение префетча добавляет в синтетических тестах около 20% производительности.
В конце поста вы почему-то говорите про ZIL, и упоминаете «буфер 50 Гб». ZIL тут ни при чём, он используется только в сценарии с синхронной записью. При асинхронной лог не пишется, и ZIL не задействуется. ARC — да, работает всегда. Правда, непонятно, почему вы решили зажать ARC на четверть объёма оперативы. Если у вас это чистая хранилка, то отдайте ему всё, что он сможет забрать.
Далее, судя по параметру --runtime=60 в тестах, вы запускали тесты всего на 60 секунд. Ясное дело, что никакие кэши тут не помогут — они просто прогреться не успевают.
И компрессию на ZFS вы выключили совершенно напрасно. Сжатие снижает число реальных ИОПСов, долетающих до дисков.SyCraft Автор
09.12.2017 10:15Префетч выключен по умолчанию в последних версиях zfsonlinux.
По тексту опечатка про ZIL, спасибо
ExH
09.12.2017 20:30+11. Вы не правильно установили размер блока для 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
Сделать это после проведения каждого теста. Каждый тест начинать после полного ребута машины.SyCraft Автор
09.12.2017 21:141 Предварительно проверил
smartctl -a /dev/sdb | grep 'Sector Size'
Sector Sizes: 512 bytes logical, 4096 bytes physical
2 Может быть я не получил максимальные показатели но имею возможность сравнить разницу
3 Это давно выключено по умолчанию в zfsonlinuxExH
09.12.2017 21:36+11. Ваш smartctl не знает про 8k блоки. Проведите тесты с ashift=13.
Наш опыт показывает что так явно будет быстрее.
А также опыт коллективного разума говорит о том же.
www.reddit.com/r/zfs/comments/3tyyj7/why_doesnt_recordsize_default_to_blocksize
gmelikov
11.12.2017 11:413) по умолчанию prefetch включён https://github.com/zfsonlinux/zfs/blob/master/man/man5/zfs-module-parameters.5#L1625
gluko
11.12.2017 08:34Во-первых, спасибо за проделанную работу! Я теперь хотя бы знаю как в линуксе можно тестировать файловые системы!
Во-вторых, прошу вас напишите, что ZFS хоть и медленная при записи (быстрая при чтении), но обладает огромным преимуществом перед классическими файловыми системами. Механизмом снимков и COW дизайном.
Собственно из-за некоторых из преимуществ у нее такая медленная запись, т.к. она имеет транзакционную природу и запись производится в несколько этапов. Для особых случаев, где важна и скорость и надежность данных, можно добавить Intel Optane в пул ZFS, в качестве Log устройства.
То есть я хочу сказать, что скорость не всегда главное и вы можете отпугнуть людей. Часто ZFS работает «достаточно» быстро и в этом случае не вижу причин ее не использовать.
Сравнение было бы более корректно с любой другой COW файловой системой со встроенными снимками или с LVM + рэйд
Снимки и надежность очень важны!
gmelikov
11.12.2017 11:37Извините, так вы что тестируете, работу с файлами, или гипервизор? Для бенчмарка гипервизора (к примеру, на 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. Жалко видеть разочарование от труда многих людей, когда вы разбираются в причинах таких результатов.
SyCraft Автор
11.12.2017 13:36Я ни слова ни написал что ZFS это плохо или хорошо)
проигнорирован recordsize (что больше всего проблем вам и даёт)
согласен, наверное.
тестируется dataset, когда в гипервизоре будет применяться vdev
Как я писал выше, виртуальный машины лежат в raw файлах поверх ext4
забыли о xattr=sa (иначе на каждую операцию с метаданными на линуксе вы прибавляете по несколько io)
тут не могу прокомментировать
не оптимальный ashift
почему? какой оптимальный и почему?
raid контроллер (даже в режиме it mode это не лучший вариант), тем более для ssd
почему?
игнорируете cow природу zfs, на гипервизоре её возможности вам очень понадобятся, при использовании снапшотов ощутите отсутствие нагрузки, которая раньше была при создании бекапов
почему вы решили что я это игнорирую?gmelikov
11.12.2017 15:58Как я писал выше, виртуальный машины лежат в 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.
acmnu
Классический Raid на SSD не самое удачное решение. Для Raid 5/6 ещё куда ни шло, хотя уже существуют более удачные для SSD варианты: разнообразные "матричные" решения в проприетарных сторожах. А вот RAID10 выглядит очень плохим вариантом из-за низкой надежности. Дело в том, что HDD умерали по механическим причинам и даже при равномерной нагрузке поломки проиходили в разное время. А вот SSD умирает по счетчику и при равномерной нагрузке очень велика вероятность близкого к одновременному выходу из строя.
SyCraft Автор
Спасибо, а какова альтернатива? если не считать железные проприетарные решения?
acmnu
Пока не видел.
SyCraft Автор
Аналогичная проблема. Главное делать бекапы )
tbp2k5
А насколько вообще реальна проблема? В «enterprise» системах счетчик по которому «умирает» SSD многократно перекрывает ожидаемое время эксплуатации системы. У нас вот ЕМСшному SANу пошел шестой год — ни одной замены SSD, VTL от Quantum — аналочно, NetApp-овский NAS — та-же история. Даже SSD на терминалах горят исключительно редко…
TheRaven
По этому мы заменяем SSD в рейдах планово, через промежутки времени.
acmnu
Вроде тут какой-то крупный хостер говорил, что они тупо ставят чипы разного производителя в зеркало.
SyCraft Автор
Тоже хорошая идея
SyCraft Автор
Как часто?
TheRaven
Пол-года год, в зависимости от нагруженности железки. Потом эти диски идут на что-нибудь менее ответственное.
SyCraft Автор
Спасибо, прогноз не утешительный. Интересно, у них MLC диски были?
Kopart
Если так быстро они у вас подходят к границе, то были случаи, что диски выходил из строя из-за полного исчерпания ресурса перезаписи ячеек?
* А то ходят легенды, что еще ни один новый SSD не умер по причине исчерпания ресурса перезаписи в ячейках (ну, возможно, с учетом резервных ячеек).
TheRaven
За этот срок они не подходят к границе, тестирование выведенных из эксплуатации показывает, что им еще работать и работать. Это делается именно для исключения ситуации «исчерпали ресурс все вместе». Насколько я знаю, сейчас срок ратирования увеличили.
Полного исчерпания не было, но вот несколько SSD со скоростью работы USB-флешки я наблюдал. гораздо больше их попередохло из-за выхода из строя контроллеров.