Всем привет! В сети довольно много материалов, посвященных файловой системе (далее ФС) ZFS, ее развитию в Linux'е и практическому применению. Меня данная ФС очень заинтересовала в контексте совершенствования моего домашнего сервера виртуализации ( а также благодаря посту пользователя kvaps), однако я не смог найти в интернете (может быть плохо искал?) сравнительных тестов производительности виртуализированных машин. Поэтому решил собрать тестовую платформу для проведения своего сравнительного исследования.
Моя статья не претендует на какие-либо научные открытия, вряд ли поможет профессионалам, которые давно работают с ZFS, и знают все ее возможности, однако поможет новичкам приблизительно оценить «цену» каждого гигабайта поделенного на производительность.
Суть эксперимента заключалась в следующем: на машину устанавливалась (каждый раз с загрузочного диска) ОС Proxmox VE 5.2. Во время установки выбирался Один из вариантов XFS/ZFS. После этого создавалась виртуальная машина, на которую производилась установка Windows Server 2008 R2, после чего запускалась популярная утилита CrystalDiskMark 5.2.2 и проводились тесты на объемах 1, 4,
Тест на ФС XFS использовался для измерения эталонной скорости работы одного ЖД (возможно это и неправильно, но других вариантов ее оценить я не придумал).
Тесты ZFS RAID 0, RAID 1 проводились на двух случайно выбранных дисках, ZFS RaidZ1 на 3 дисках, ZFS RAID 10, RaidZ2 на 4 дисках. Тесты с ZFS RaidZ3 не проводились по причине отсутствия желания купить еще один крайне экономически нецелесообразный HDD на 500GB.
Под спойлером кратко приведу описания каждого из видов ZFS RAID с моим примером получаемого объема «коммерческих» гигабайтов:
- ZFS RAID 0 — чередование (Striped), объем 2 * DiskSize = 1000ГБ.
- ZFS RAID 1 — зеркалирование (Mirror), объем 1 * DiskSize = 500ГБ.
3 диска:
- ZFS RaidZ1 — он же ZFS RaidZ, аналог RAID5, объем (N — 1) * DiskSize = 1000ГБ.
4 диска:
- ZFS RAID 10 — зеркалирование с чередованием (Striped Mirrored), объем 2 * DiskSize = 1000ГБ.
- ZFS RaidZ2 — аналог RAID6, объем (N — 2) * DiskSize = 1000ГБ.
- при этом, я такой тест не проводил, но ZFS RaidZ1 при 4 дисках = 1500ГБ.
Очень понятно расписана суть вот тут (англ). А также сколько дисков допустимо потерять, сохранив информацию.
Хочется отметить, что помимо различной скорости доступа файловой системы, еще нужно учитывать общий объем получаемого массива, и надежность сохранности данных, в случаях выхода из строя жестких дисков.
Технические характеристики платформы, (возможно) влияющие на результаты тестирования:
- Материнская плата: Intel Desktop Board DS67SQ-B3;
- Процессор: Intel Pentium G630 2.7GHz;
- Оперативная память: 2 x 4096Mb Hynix PC3-10700;
- Жесткие диски: 3 x WD 5000AZRX 500GB SATA 64MB Cache, 1 x WD 5000AZRZ 500GB SATA 64MB Cache, SSD SATA Goldenfir T650-8GB;
- Блок питания: DeepCool DA500N 500W.
Виртуальной машине (KVM) для тестов выделялось 4GB оперативной памяти, 1 ядро процессора, жесткий диск VirtIO Block 100GB.
Для систем, установленных на ZFS выполнялось 2 теста, во втором в качестве кэш-диска подключался SSD.
Все результаты представлены в виде скриншотов ниже. Если у кого-нибудь возникнет желание оцифровать данные результаты — буду благодарен и включу результаты работы в статью.
Спасибо всем кто уделил внимание, надеюсь для кого-то данная выборка окажется, как и для меня, полезной.
P.S. по непонятным мне причинам часть изображений куда-то пропали, замеры проводились в конце весны, тестовую платформу уже не собрать в том виде, к счастью все они приходятся на тесты с 32 GiB.
P.P.S. Не пытался рекламировать какие-либо организации и/или программные продукты, не имел цели нарушить лицензионных соглашений, если где-то был неправ, прошу писать в личные сообщения.
P.P.P.S. Изображение с логотипом ZFS является репродукцией.
Комментарии (48)
blind_oracle
16.09.2018 19:10Юзаю ZFS дома в самопальном NAS довольно давно.
На RAID-Z1 из 4 низкооборотных дисков при даже не сильно активной работе торрент-клиента пользоваться NAS практически нереально — I/O Wait 100% одного ядра, куча IOPS на диски.
Особых бенчмарков не проводил, но когда аналогичный NAS был на RAID-5/XFS подобных проблем не возникало.thatsme
16.09.2018 19:49Это из за ARC кэша, он очень любит ОЗУ. Тюнить при отсутствии хотя-бы 8ГБ ОЗУ на системе, неблагодарное занятие. Всё-таки ФС расчитана на суровый энтерпрайз. У меня дома ZFS RAID-10 на 6 дисках (3 зеркала), и ОЗУ на компе 64ГБ, вобщем тюнить даже не тянет.
blind_oracle
16.09.2018 19:54ОЗУ 8Гб на текущем NAS, кеши не тюнил. Кроме ZFS там память никто не жрет особо.
Текущий объем ARC 1.8Gb, может стоит разрешить ему кушать побольше чем 25%.
До этого имел долгий опыт жизни с «NAS» из 10 7.2k SATA дисков в RAID-Z2 при 256Gb RAM (такой вот франкенштейн), по дурости думал что такой объем памяти мне позволит сделать дедупликацию без снижения производительности… угу, щас. Удаление большого файла вызывало дикие локапы всей системы. Когда ее убрал — стало по-божески, но это 256Гб все таки.a0fs
16.09.2018 20:12А зачем на файлопомойке урезать ARC? Мне для общего развития… На Linux я его подрезал до 75% исключительно из-за того, что он (linux) иногда начинает драться с ZFS за память. Если их растащить таким способом, всё становится нормально (debian 7, давно дело было). Но до 25% это террор, особенно если учесть, что ARC сильно продвинутее чем кеш ОС.
blind_oracle
16.09.2018 20:20А я не ограничивал, все по дефолту.
Он, насколько я помню, лимитируется в 50% RAM если zfs_arc_max=0.
Почему он у меня меньше 50% — хз, возможно сдувается под давлением обстоятельств :) На глаз 25% как раз.a0fs
16.09.2018 20:22Просто ему нечего кешировать, всё нормально =)))
b0sun
18.09.2018 16:12так не бывает ) после первый же отгруженного в Torrent фильма ARC должен занять явно больше 2 ГБ… Главный профит ARC — хранение метаданных файловой системы. Ну и чтение, разумеется. Если объём памяти ограничен — атрибут primarycache=metadata для ФС должен помочь. Содержимое самих файлов не будет вымывать из кэша структуру, соотв, ZFS всегда знает, где лежит тот или иной блок и куда положить новый.
paul35 Автор
16.09.2018 22:20Это у вас дома такие франкенштейны обитают?
blind_oracle
16.09.2018 22:23Да, купил списанный сервер с двумя Xeon E5 и 256Гб т.к. нужно было гонять жоркие до памяти вычисления. Сейчас стоит ненужный уже, буду продавать наверное.
paul35 Автор
16.09.2018 22:36Завидую вам!
Я для апа своей старой железки уже пару месяцев не могу найти DDR2 ECC unbuffered памяти, поэтому пользуясь случаем кину здесь свою просьбу у кого есть ненужные 4 x 2 GB модули 667 или 800 MHz, я готов их купить, писать в личку.
a0fs
16.09.2018 20:06Живу на 4 Гигах на машине с второй корой дуба (Core2 Duo) диски на родном контроллере чипсета. Всё в норме, память оно жрёт, но если нужно отпускает. Правда есть некоторый чит, живу я на FreeBSD. ZFS может работать и с 2-я гигами памяти, весь вопрос в том, что при меньшем количестве памяти, будут больше работать диски. 8 Гигов — это для файлопомойки достаточно много, если при этом диски не в raidz и их не много, смысла в этом большого нет ИМХО.
a0fs
16.09.2018 20:00+1Что-то пошло не так, ZFS использует deadline в качестве планировщика и никогда не кладёт диски в полку на 100%. Может подтормаживать ввод-вывод, но совсем капец наступить не должен. Отзывчивость чтения должна быть на уровне. Можно попробовать recordsize увеличить, если включён large_blocks `zfs get feature@large_blocks $dataset_name` то можно поставить 1 Мбайт. Это уменьшит количество запросов блоков (в среднем один блок в торрентах где-то 1-4 Мбайта) и разгрузит очередь. Но у меня ZFS диски не ложил. XFS легко, EXT4 — это его нормальное состояние, ZFS никогда.
blind_oracle
16.09.2018 20:10У меня отдельный ZFS датасет под торренты с блоком в 16к по рекомендации лучших собаководов отсюда: www.open-zfs.org/wiki/Performance_tuning#Bit_Torrent
И когда работают торренты у меня стандартно 20-30% I/O wait (из 4 ядер), вот скрин из заббикса:
OS Ubuntu 16, ZoL последний, диски HGST какие-то около 5-6к оборотов.a0fs
16.09.2018 20:151 блок торрента в среднем 1 мегабайт, для отдачи одного блока в очередь попадает 1024/16 команд на загрузку данных. И получается советская очередь за молоком. Лучше увеличить по среднему размеру блока в торрентах.
blind_oracle
16.09.2018 20:21Возможно, я не вдумывался, сделал как в доках сказано. Погляжу статистику I/O — какие размеры операций идут. Спасибо.
blind_oracle
16.09.2018 21:49Помониторил:
# zpool iostat 10
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
bkp 799G 1.94T 0 0 0 0
zfs 5.95T 4.61T 799 0 14.0M 0
---------- ----- ----- ----- ----- ----- -----
bkp 799G 1.94T 0 0 0 0
zfs 5.95T 4.61T 773 0 15.3M 0
---------- ----- ----- ----- ----- ----- -----
bkp 799G 1.94T 0 0 0 0
zfs 5.95T 4.61T 813 0 17.1M 0
---------- ----- ----- ----- ----- ----- -----
Судя по этим данным средний размер I/O 46400/2385=19.4 килобайта, что примерно соответствует моему размеру блока в 16k.
Так что, по крайней мере мой transmission, не читает блоками по 1М.a0fs
16.09.2018 23:22Он читает блоками, если блок 16, он читает 16. При изменении размера блока, все новые файлы будут писаться на новый размер, тогда может быть выигрыш. Я размер блока посмотрел в статистике своего клиента глазами, может более суровое исследование даст лучший результат. Но кажется что мегабайт будет нормально, тем более, что больше вроде пока нельзя, да и мегабайт можно только с соответствующей опцией.
Я смотрел видео, где человек рассказывал о использовании ZFS на серверах раздачи видеоконтента, и он сильно агитировал за больший размер блока.blind_oracle
17.09.2018 14:29Проблема в том, что если блок ФС 1М, а блок торрента 16к, то запись блоков по 16к будет вызывать read-modify-write всего 1М блока (для пересчета контрольной суммы, разливания по RAID-Z и т.п.). Поэтому я не уверен что это не ухудшит дела, хотя стоит проверить.
zpool все таки показывает что чтение идет блоками в районе 20к, а не 1М. Попробую посмотреть при записи что происходит.
justabaka
16.09.2018 19:18Очень странно видеть сравнение не со схожей конфигурацией под управлением mdraid, а одним диском под XFS.
5m1l3
16.09.2018 20:50+1Непонятно также почему выбран Virtio-Block, хотя прокс рекомендует Virtio-Scsi. Ну и цифры эти они о погоде на луне, я раньше тоже так тестил. Имхо если ставим гипервизор, то наверное будет несколько виртуалок, иначе какой смысл в прослойке, если будет несколько виртуалок, то картинка может сильно поменяться, поэтому таких тестов и нету, желательно тестить c помощью fio непосредственно на хосте гипервизора.
paul35 Автор
16.09.2018 22:15Непонятно также почему выбран Virtio-Block, хотя прокс рекомендует Virtio-Scsi
Мне в данный момент тоже непонятно почему я такой выбор сделал )
то наверное будет несколько виртуалок, иначе какой смысл в прослойке
ну зная скорость на одной можно сделать некоторые выводы, мне хотелось понять именно разницу в скорости между этими реализациями
желательно тестить c помощью fio непосредственно на хосте
ну меня в этих тестах интересовало что именно дойдет до виртуалки.
Вот для сравнения, да простят меня все линуксоиды, сравнительный тест в среде MS
Гипервизор (не Hyper-V) на Server 2016 (это уже на другой железке тесты)
SOFT RAID 5
bfuvx
17.09.2018 00:24Непонятно также почему выбран Virtio-Block, хотя прокс рекомендует Virtio-Scsi.
Именно в вопросе производительности это не сильно важно. Proxmox рекомендует virtio-scsi скорее из-за большего количества функций (полноценное scsi устройство, поддержка blkdiscard, масштабируемость и т.д.) при примерно той же производительности (при некоторых паттернах нагрузки она хуже из-за большего количества прослоек).5m1l3
17.09.2018 01:39ну меня в этих тестах интересовало что именно дойдет до виртуалки.
100% практически и дойдет, именно в этом цель virtio драйверов.
Вот для сравнения, да простят меня все линуксоиды, сравнительный тест в среде MS
Гипервизор (не Hyper-V) на Server 2016 (это уже на другой железке тесты)
Вы же понимаете что так не бывает и где-то в тестах косяк? Если на физ. машине действительно запись всего 30 МБ/с, то на виртуалке ну никак 85 не будет. Имхо вы просто не пробили тут кеш 1 гиговым файлом.
Также хотелось бы подробностей, вы написали что для кеша использовали SSD, как L2Arc? А то там можно еще SSD подключить как Zil, тогда еще и запись ускорится.
paul35 Автор
18.09.2018 16:11ZFS l2arc cache device
А то там можно еще SSD подключить как Zil, тогда еще и запись ускорится.
Я так понимаю для этого нужен еще один SSDb0sun
19.09.2018 03:56профит от SSD ZIL несколько переоценивают. Если не включена принудительная синхронизация тома, и приложение не запрашивает fsync после IO — ZIL не участвует.
sHaggY_caT
16.09.2018 19:38В большей степени были бы полезнее iops'ы а не скорость чтения/записи
thatsme
16.09.2018 19:50А IOPS-ы от шпинделей. Выше производительности дисков не прыгнешь.
zmejg
19.09.2018 14:30Не всё так однозначно, если учесть сколько всего ФС пихает в память и ARC/ZIL. Тестировал при помощи утилиты ioping на VM-ках и цифры на ZFS всегда были на порядок выше. Например если на ufs/ext3/ext4 ~2k, то на ZFS ~70-80k. Шпинделя были одни и те же.
C методикой тестирования действительно надо бы определиться что бы не сравнивать разрозненные величины. Для меня это так и осталось открытым вопросом.
paul35 Автор
16.09.2018 22:18Если читающим это действительно интересно, напишите какие тесты провести, что замерять. Сейчас на некоторое время есть свободная железка, правда с более слабым конфигом (C2D, 6GB RAM и тот же набор дисков).
sHaggY_caT
16.09.2018 23:05zil на SSD и не на SSD, для разных конфигураций (raid-z, raid-z2 итд), L2ARC на SSD, и без него, разные размеры ARC — для всего этого iops, а не мегабайты(мегабиты) в секунду.
paul35 Автор
16.09.2018 23:51У меня нет такого количества SSD, я же написал, что с тем же набором дисков. Все эти тесты проводятся дома, на работе нет свободного железа, да и разрешения руководство на такое никогда не даст )
midaw1
16.09.2018 22:34Из статьи и из моего опыта можно сделать грустный вывод. Сколько дисков zfs не дай, а скорость записи будет просто смешной. Да и xfs в вашей виртуалке в 100мб/сек — тоже отстой. В ntfs win эти диски могут показывать более 180мб/сек, верно?
paul35 Автор
16.09.2018 23:54Сейчас под рукой нет результатов тестов на одиночных дисках, а результаты RAID5 приводил чуть выше,
paul35 Автор
18.09.2018 16:00Сколько дисков zfs не дай, а скорость записи будет просто смешной.
Вот тут я думаю ваш вывод абсолютно верный! И исходя из целей и задач виртуализированных ОС для кого-то ZFS не будет иметь никакого смысла. В ближайшей перспективе хочу провести сравнение с mdadm.midaw1
19.09.2018 00:38нене, имеет смысл. но только, если это SSD и включена дедупликация. к сожалению и там есть провалы в скорости записи. использую zfs на evo 960. есть ощущение, что там не работает trim.
achekalin
17.09.2018 13:03XFS для Proxmox вроде не самая дефолтная ФС, там же Debian в основе, и дефолтом шла и имет ext3/ext4. Вы их не меряли?
И вот каком момент: когда речь заходит о ext4 (или xfs, как вы взяли), обычно говорят о томе RAID (ставить гипервизор не на резервированное хранилище довольно смело, и так делают только под очень узкие задачи), так вот RAID с батарейкой, а особенно с SSD-кешем, может существенно повлиять на результаты — в таком варианте не замеряли?
И ZFS — какие настройки по памяти делали? ОС хоста, гипервизор и сами ОЗУ потребляют, да еще ZFS умеет любит ОЗУ использовать — так вот какими настроками/мануалами пользовались для тюнинга?paul35 Автор
18.09.2018 15:56дефолтом шла и имет ext3/ext4. Вы их не меряли?
У сожалению — нет!
RAID с батарейкой
У меня такое оборудование отсутствует! Это SOHO уровень!
И ZFS — какие настройки по памяти делали?
Все настройки дефолтные при установке ProxMox VE, специально ничего не менял.
RStarun
17.09.2018 14:16Ну как так-то?
Почему в случае с включенным кэшем мы получаем производительность сильно ниже, даже на мелких 4 и 1 гб файлах. Сравните ZFS Raid1 и Raid1 + кеш.
divanikus
17.09.2018 15:23По теме рекомендую почитать также труды вот этого чела:
jrs-s.net/2013/05/17/kvm-io-benchmarking
jrs-s.net/2018/03/13/zvol-vs-qcow2-with-kvm
Очень познавательно.
amarao
17.09.2018 15:33Десятикратный прирост производительности на ZFS vs XFS? Можно, я просто не поверю? Это либо прогретые кеши, либо writeback.
Каждый раз, когда мне пытаются продать увеличение производительности диска в 10 раз, я обнаруживаю внутри writeback. Иногда с игнором flush'ей.paul35 Автор
18.09.2018 15:53Во всех тестах процедура была абсолютно идентична: 1. установка прокса; 2-установка ws; 3- тест.
Увеличения в 10 раз вроде и нет, максимум в 5 раз. Мне кажется это возможно при распараллеливании доступа к дискам.
paul35 Автор
Не могу разместить ссылку на PDF документ со сводной таблицей, я еще маленький для этого?