Предисловие скопировано из Part 1.
С момента прошлой статьи прошло 2 года (и за время написания статьи ещё полгода), за это время:
количество дисков в системе увеличилось до 8 PM9A3 1.92TB;
вышло несколько новых прошивок на PM9A3;
сеть обновилась с ConnectX-3 Pro 40G до ConnectX-4 100G;
В связи с этим - было решено заново провести тесты.
У данной статьи такие же две цели, как и у прошлой:
Протестировать производительность трёх систем объединения физических устройств в одно логическое, как для локального доступа к нему, так и для использования в качестве блочного массива для виртуализации.
Создание бэкэнда для кластера в виде одноконтроллерного хранилища.
Иными словами выводы данной статьи не применимы, когда Вам нужно:
Синхронное отказоустойчивое решение
Надежность >>> скорость
Долговременное решение, которое можно поставить и забыть
0. Оглавление
0) Оглавление
1) Описание тестового стенда
2) Общая настройка серверов
2.1) Особые условия
3) iSER
3.1) Raw Data
3.2) VDbench - 4k - 100% rng - 100% Write
3.3) VDbench - 4k - 100% rng - 100% read
3.4) VDbench - 4k - 80% rng - 50/50 r/w
3.5) VDbench - 64k - 80% rng - 75/25 r/w
3.6) VDbench - 8k - 80% rng - 75/25 r/w
3.7) FIO - 256k - 0% rng - 0/100 r/w
3.8) FIO - 4k - 100% rng - 100/0 r/w
3.9) FIO - 4k - 100% rng - 70/30 r/w
3.10) FIO - 8k - 100% rng 70/30 r/w
3.11) Сравнение софт рейдов
3.11.1) Raid0
3.11.2) Raid5
4) NVMe-oF
4.1) Проблемы Next-Next-Next для NVMe-oF
4.2) Raw Data
4.3) VDbench - 4k - 100% rng - 100% Write
4.4) VDbench - 4k - 100% rng - 100% read
4.5) VDbench - 4k - 80% rng - 50/50 r/w
4.6) VDbench - 64k - 80% rng - 75/25 r/w
4.7) VDbench - 8k - 80% rng - 75/25 r/w
4.8) FIO - 256k - 0% rng - 0/100 r/w
4.9) FIO - 4k - 100% rng - 100/0 r/w
4.10) FIO - 4k - 100% rng - 70/30 r/w
4.11) FIO - 8k - 100% rng 70/30 r/w
4.12) Сравнение софт рейдов
4.12.1) Raid0
4.12.2) Raid5
1. Описание тестового стенда
Сервер виртуализации 1:
Motherboard: Supermicro H11SSL-i
CPU: EPYC 7302
RAM: 4x64GB Micron 2933MHz
Сеть SAN: 100GbE ConnectX-4 MT27700
Сеть LAN: 10GbE/25GbE ConnectX-4 LN EN
ОС: ESXi 7U3 build 20036586
Сервер виртуализации 2:
Motherboard: Supermicro H11DSI-NT
CPU: EPYC 7302 x2
RAM: 16x32GB Samsung 3200 MHz
Сеть SAN: 100GbE ConnectX-4 MT27700
Сеть LAN: 10GbE/25GbE ConnectX-4 LN EN
ОС: ESXi 7U3 build 20036586
Сервер хранения (гибридный сервер с PCIe Passthrough):
Motherboard: Tyan S8030 (ver 1GbE)
CPU: EPYC 7F52
RAM: 4x64GB Micron 2933MHz
Сеть SAN: 100GbE ConnectX-4 MT27700 x2
Сеть LAN: 10GbE/25GbE ConnectX-4 LN EN
Диски: 8 x PM9A3 1.92TB, форматированы в 512n
ВМ: Ubuntu 24.04 (6.11.0-26)
ZFS: 2.4.0
Схема подключения для тестов NVMe-oF и iSER:
2. Общая настройка серверов.
(назад к оглавлению)
Для тестирования была создана ВМ с iSER (LIO) и NVMe-oF (SPDK) таргетом, для NVMe-oF тестов параметры ВМ оставались неизменные, кроме ZFS тестов, а именно 6 ядер, 64ГБ памяти.
Для ZFS - в случае iSER память была расширена до 128ГБ, а в случае с NVMe-oF размер ВМ увеличен до 8 ядер и количество оперативной памяти до 128ГБ.
Конфигурация нагрузочных ВМ HCIbench-а
FIO тесты:
По 2 ВМ на хост (6 ВМ суммарно)
8 vCPU
16GB оперативной памяти
8 дисков по 32ГБ
vdbench тесты:
По 2 ВМ на хост (6 ВМ суммарно)
8 vCPU
16GB оперативной памяти
2 диска по 100ГБ
Конфигурация FIO
Тесты являются тестами из пресета vsan easyrun
Последовательная запись 256k
fio-8vmdk-100ws-256k-0rdpct-0randompct-1threads
[global]
runtime=600
time_based=1
ramp_time=360
direct=1
buffered=0
fsync=0
readwrite=write
random_generator=tausworthe64
blocksize=256K
ioengine=libaio
group_reporting
lat_percentiles=1
continue_on_error=all
[job0-7]
filename=/dev/sda
size=100%
iodepth=1
Случайное 100% чтение 4k
fio-8vmdk-100ws-4k-100rdpct-100randompct-4threads-50compress-50dedupe
[global]
runtime=600
time_based=1
ramp_time=360
direct=1
buffered=0
fsync=0
readwrite=randread
random_generator=tausworthe64
blocksize=4K
buffer_compress_percentage=50
dedupe_percentage=50
ioengine=libaio
group_reporting
lat_percentiles=1
continue_on_error=all
[job0-7]
filename=/dev/sd[a-h]
size=100%
iodepth=4
Случайное 70% чтение 30% запись 4k
fio-8vmdk-100ws-4k-70rdpct-100randompct-4threads-50compress-50dedupe
[global]
runtime=600
time_based=1
ramp_time=360
direct=1
buffered=0
fsync=0
readwrite=randrw
rwmixread=70
percentage_random=100
random_generator=tausworthe64
blocksize=4K
buffer_compress_percentage=50
dedupe_percentage=50
ioengine=libaio
group_reporting
lat_percentiles=1
continue_on_error=all
[job0-7]
filename=/dev/sd[a-h]
size=100%
iodepth=4
Случайное 50% чтение 50% записи 8к
fio-8vmdk-100ws-8k-50rdpct-100randompct-4threads-50compress-50dedupe
[global]
runtime=600
time_based=1
ramp_time=360
direct=1
buffered=0
fsync=0
readwrite=randrw
rwmixread=50
percentage_random=100
random_generator=tausworthe64
blocksize=8K
buffer_compress_percentage=50
dedupe_percentage=50
ioengine=libaio
group_reporting
lat_percentiles=1
continue_on_error=all
[job0-7]
filename=/dev/sd[a-h]
size=100%
iodepth=4
Конфигурация vdbench
Тесты взяты отсюда
100% cлучайная запись 4к, 4 потока на диск
vdb-2vmdk-100ws-4k-0rdpct-100randompct-4threads
2 raw disk, 100% random, 0% read
sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4
sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4
wd=wd1,sd=(sd1,sd2),xfersize=4k,rdpct=0,seekpct=100
rd=run1,wd=wd1,iorate=max,elapsed=300
100% случайное чтение 4к, 4 потока на диск
vdb-2vmdk-100ws-4k-100rdpct-100randompct-4threads
2 raw disk, 100% random, 100% read
sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4 sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4 wd=wd1,sd=(sd1,sd2),xfersize=4k,rdpct=100,seekpct=100 rd=run1,wd=wd1,iorate=max,elapsed=300
80% случайное, 20% последовательное, 50% чтение 50% записи 4к, 4 потока на диск
vdb-2vmdk-100ws-4k-50rdpct-80randompct-4threads
2 raw disk, 80% random, 50% read
sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4 sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4 wd=wd1,sd=(sd1,sd2),xfersize=4k,rdpct=50,seekpct=80 rd=run1,wd=wd1,iorate=max,elapsed=300
80% случайное, 20% последовательное, 75% чтение 25% записи 64к, 4 потока на диск
vdb-2vmdk-100ws-64k-75rdpct-80randompct-4threads
2 raw disk, 80% random, 75% read
sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4 sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4 wd=wd1,sd=(sd1,sd2),xfersize=64k,rdpct=75,seekpct=80 rd=run1,wd=wd1,iorate=max,elapsed=300
80% случайное, 20% последовательное, 75% чтение 25% записи 8к, 4 потока на диск
vdb-2vmdk-100ws-8k-75rdpct-80randompct-4threads
2 raw disk, 80% random, 75% read
sd=sd1,lun=/dev/sda,openflags=o_direct,hitarea=0,range=(0,100),threads=4 sd=sd2,lun=/dev/sdb,openflags=o_direct,hitarea=0,range=(0,100),threads=4 wd=wd1,sd=(sd1,sd2),xfersize=8k,rdpct=75,seekpct=80 rd=run1,wd=wd1,iorate=max,elapsed=300
Настройки хоста со стороны BIOS
Для настроек BIOS помогли эти две статьи (#1, #2):
NPS=1
L3 Cache as NUMA domain = Disabled
IOMMU = Enabled
PCIe Ten Bit Tag Support = Enabled
Prefered IO = Manual
Preferred IO Bus = <conntectX-4 pcie ID из lspci>
APBDIS = 1
Fixed SOC P-state=P0
DF C-states=Disable
Global C-State Control =Enable
Determinism Control = Manual
Determinism Enable = Power
TDP Control = Manual
TDP = <max CPU TDP>
PPT Control = Manual
PPT = <max CPU TDP>
Для наглядности Google Spreadsheet:
https://docs.google.com/spreadsheets/d/1f49vAqj-m4n4sSb8tD-PahenhBxXMx4Ju0QM_RvhU38/edit?usp=sharing
2.1 Особые условия
(назад к оглавлению)
В силу того, что SPDK работает по пуллинг принципу - он занимает все ядра, что ему отдали всегда на 100%. Поэтому процессам, которые хотят взять себе ресурсов, к примеру, для рассчёта parity возникает определённая проблема, включая даже банально, что так как LVM считает себя более приоритетным, SPDK ломается и теряет QID генерирую дубликаты.
Скрытый текст
spdk[2136]: ctrlr.c: 299:nvmf_ctrlr_add_qpair: WARNING: Duplicate QID detected (cntlid:2, qid:1), re-check in 1000us
spdk[2136]: ctrlr.c: 329:_retry_qid_check: WARNING: Retrying adding qpair, qid:1
spdk[2136]: ctrlr.c: 291:nvmf_ctrlr_add_qpair: ERROR: Got I/O connect with duplicate QID 1 (cntlid:2)
spdk[2136]: ctrlr.c: 299:nvmf_ctrlr_add_qpair: WARNING: Duplicate QID detected (cntlid:3, qid:1), re-check in 1000us
spdk[2136]: ctrlr.c: 329:_retry_qid_check: WARNING: Retrying adding qpair, qid:1
spdk[2136]: ctrlr.c: 291:nvmf_ctrlr_add_qpair: ERROR: Got I/O connect with duplicate QID 1 (cntlid:3)
spdk[2136]: ctrlr.c: 299:nvmf_ctrlr_add_qpair: WARNING: Duplicate QID detected (cntlid:3, qid:2), re-check in 1000us
spdk[2136]: ctrlr.c: 329:_retry_qid_check: WARNING: Retrying adding qpair, qid:2
spdk[2136]: ctrlr.c: 291:nvmf_ctrlr_add_qpair: ERROR: Got I/O connect with duplicate QID 2 (cntlid:3)
spdk[2136]: ctrlr.c: 299:nvmf_ctrlr_add_qpair: WARNING: Duplicate QID detected (cntlid:2, qid:2), re-check in 1000us
spdk[2136]: ctrlr.c: 329:_retry_qid_check: WARNING: Retrying adding qpair, qid:2
spdk[2136]: ctrlr.c: 291:nvmf_ctrlr_add_qpair: ERROR: Got I/O connect with duplicate QID 2 (cntlid:2)
Решением стало:
1) Уменьшение количество ядер отданных инициатору до 2 в случае с LVM Raid5, и до 4 в случае с ZFS Stipe и RaidZ
2) Увеличение размера ВМ с SPDK с 6 до 8 ядер.
Также для тестов ZFS все диски сперва были пропущены через blkdiscard с ожидаем после этого в 1 ночь, чтобы контроллер отработал все фоновые задачи.
3. iSER
(назад к оглавлению)
iSER особо не поменялся и его настройка всё такая же, что со стороны Вари, что со стороны Linux (targetcli)
На уровне IQN:
set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1
На уровне LUN-а:
set attribute emulate_3pc=1 emulate_tpu=1 emulate_caw=1 max_write_same_len=65535 emulate_tpws=1 is_nonrot=1
3.1 Raw Data
(назад к оглавлению)
Сырые значения сгруппированы по типу использованного софт рейда. Графические данные по имени теста.
MDADM Raid0
| MDADM Raid0 | |||
iSER | IOPS | MB/s | CPU util | latency |
VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk | 284 723.17 | 1 112.19 | 6.20% | 0.17 |
VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk | 225 953.33 | 882.63 | 7.00% | 0.21 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE | 257 869.23 | 1 007.30 | 8.27% | 0.16 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ | 0.21 | |||
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 88 482.30 | 5 530.14 | 9.10% | 0.53 |
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ | 0.56 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 227 262.77 | 1 775.49 | 10.28% | 0.17 |
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ | 0.22 | |||
Последовательная запись 256к (vsan easyrun) | 11 166.15 | 2 790.67 | 7.25% | 4.57 |
Случайное 100% чтение 4k (vsan easyrun) | 361 540.68 | 1 411.67 | 8.97% | 0.53 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE | 367 324.14 | 1 434.33 | 12.24% | 0.49 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) READ | 0.54 | |||
Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE | 343 850.64 | 2 686.00 | 16.61% | 0.53 |
Случайное 70% чтение 30% записи 8к (vsan easyrun) READ | 0.59 | |||
MDADM Raid5
| MDADM Raid5 | |||
iSER | IOPS | MB/s | CPU util | latency |
VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk | 67 847.47 | 265.03 | 1.92% | 0.88 |
VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk | 203 026.33 | 793.07 | 3.48% | 0.24 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE | 119 058.50 | 465.07 | 4.98% | 0.70 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ | 0.21 | |||
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 24 256.00 | 1 516.00 | 4.73% | 5.76 |
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ | 0.40 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 122 714.27 | 958.70 | 5.95% | 0.67 |
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ | 0.24 | |||
Последовательная запись 256к (vsan easyrun) | 1 417.53 | 353.67 | 1.48% | 16.97 |
Случайное 100% чтение 4k (vsan easyrun) | 139 514.77 | 544.67 | 3.51% | 0.69 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE | 120 456.52 | 470.33 | 6.03% | 0.87 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) READ | 0.77 | |||
Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE | 77 749.53 | 607.00 | 7.79% | 1.45 |
Случайное 70% чтение 30% записи 8к (vsan easyrun) READ | 1.02 | |||
LVM Raid0
| LVM Raid0 | |||
iSER | IOPS | MB/s | CPU util | latency |
VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk | 299 001.83 | 1 167.97 | 12.60% | 0.16 |
VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk | 234 285.33 | 915.18 | 14.10% | 0.20 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE | 268 003.80 | 1 046.89 | 15.50% | 0.15 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ | 0.20 | |||
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 100 048.77 | 6 253.05 | 15.98% | 0.52 |
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ | 0.60 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 233 907.83 | 1 827.41 | 18.73% | 0.16 |
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ | 0.22 | |||
Последовательная запись 256к (vsan easyrun) | 18 722.06 | 4 680.00 | 4.78% | 2.64 |
Случайное 100% чтение 4k (vsan easyrun) | 350 870.49 | 1 370.33 | 6.73% | 0.55 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE | 354 473.82 | 1 384.00 | 12.09% | 0.51 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) READ | 0.56 | |||
Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE | 332 271.50 | 2 595.33 | 16.86% | 0.55 |
Случайное 70% чтение 30% записи 8к (vsan easyrun) READ | 0.61 | |||
LVM Raid5
| LVM Raid5 | |||
iSER | IOPS | MB/s | CPU util | latency |
VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk | 59 304.53 | 231.65 | 5.83% | 0.80 |
VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk | 91 895.98 | 358.97 | 6.84% | 0.52 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE | 81 976.13 | 320.22 | 7.62% | 0.71 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ | 0.45 | |||
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 13 216.58 | 826.04 | 8.13% | 7.45 |
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ | 2.36 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 77 631.65 | 606.50 | 9.56% | 0.82 |
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ | 0.55 | |||
Последовательная запись 256к (vsan easyrun) | 1 889.59 | 472.00 | 3.23% | 25.60 |
Случайное 100% чтение 4k (vsan easyrun) | 123 334.01 | 481.25 | 4.06% | 1.56 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE | 106 681.02 | 416.00 | 6.37% | 1.88 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) READ | 1.76 | |||
Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE | 73 436.82 | 573.25 | 8.07% | 2.84 |
Случайное 70% чтение 30% записи 8к (vsan easyrun) READ | 2.39 | |||
ZFS Stripe (Raid0)
| ZFS Stripe (Raid0) | |||
iSER | IOPS | MB/s | CPU util | latency |
VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk | 13 854.37 | 54.12 | 10.95% | 3.46 |
VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk | 78 314.83 | 305.92 | 11.06% | 0.61 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE | 29 376.40 | 114.75 | 11.07% | 1.82 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ | 1.45 | |||
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 18 672.80 | 1 167.06 | 11.96% | 2.31 |
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ | 2.74 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 38 804.50 | 303.16 | 14.39% | 1.26 |
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ | 1.24 | |||
Последовательная запись 256к (vsan easyrun) | 3 424.75 | 855.75 | 2.55% | 14.02 |
Случайное 100% чтение 4k (vsan easyrun) | 83 428.24 | 325.50 | 5.15% | 2.32 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE | 40 025.47 | 155.75 | 7.41% | 5.24 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) READ | 4.69 | |||
Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE | 28 179.41 | 219.75 | 8.60% | 7.34 |
Случайное 70% чтение 30% записи 8к (vsan easyrun) READ | 6.30 | |||
ZFS RaidZ (Raid5)
| ZFS RaidZ (Raid5) | |||
iSER | IOPS | MB/s | CPU util | latency |
VDbench - 4k - 100% rng - 0/100 r/w - 8 thread per disk | 12 718.27 | 49.68 | 10.10% | 3.77 |
VDbench - 4k - 100% rng - 100/0 r/w - 8 thread per disk | 72 718.70 | 284.06 | 11.33% | 0.66 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk WRITE | 24 668.73 | 96.36 | 12.59% | 2.40 |
VDbench - 4k - 80% rng - 50/50 r/w - 8 thread per disk READ | 1.49 | |||
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 15 468.27 | 966.77 | 13.69% | 2.09 |
VDbench - 64k - 80% rng - 75/25 r/w - 8 thread per disk READ | 3.51 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk WRITE | 35 068.17 | 273.97 | 15.93% | 1.39 |
VDbench - 8k - 80% rng - 75/25 r/w - 8 thread per disk READ | 1.37 | |||
Последовательная запись 256к (vsan easyrun) | 3 213.39 | 803.00 | 3.64% | 15.02 |
Случайное 100% чтение 4k (vsan easyrun) | 75 045.22 | 292.33 | 5.97% | 2.56 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE | 34 054.32 | 132.33 | 8.69% | 6.14 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) READ | 5.43 | |||
Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE | 24 047.15 | 187.33 | 10.08% | 8.63 |
Случайное 70% чтение 30% записи 8к (vsan easyrun) READ | 7.34 | |||
ZFS Stripe (Raid0) без чексумм
| ZFS Stripe nochecksum | |||
iSER | IOPS | MB/s | CPU util | latency |
VDbench - 4k - 100% rng - 0/100 r/w - 4 thread per disk | 21 469.40 | 83.86 | 6.10% | 2.23 |
VDbench - 4k - 100% rng - 100/0 r/w - 4 thread per disk | 81 155.30 | 317.01 | 8.15% | 0.59 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE | 39 117.90 | 152.80 | 10.35% | 1.29 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ | 1.17 | |||
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE | 20 887.43 | 1305.46 | 12.27% | 2.02 |
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ | 2.44 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE | 48 347.85 | 377.72 | 14.71% | 1.01 |
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ | 1.00 | |||
Последовательная запись 256к (vsan easyrun) | 3 600.64 | 899.67 | 6.37% | 13.34 |
Случайное 100% чтение 4k (vsan easyrun) | 84 736.52 | 330.33 | 6.92% | 2.27 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) WRITE | 51 076.97 | 199.33 | 7.87% | 3.94 |
Случайное 70% чтение 30% запись 4k (vsan easyrun) READ | 3.69 | |||
Случайное 70% чтение 30% записи 8к (vsan easyrun) WRITE | 37 120.03 | 289.33 | 8.95% | 5.48 |
Случайное 70% чтение 30% записи 8к (vsan easyrun) READ | 4.88 | |||
3.2 VDbench - 4k - 100% rng - 100% Write
(назад к оглавлению)
(назад к описанию теста)
3.3 VDbench - 4k - 100% rng - 100% read
(назад к оглавлению)
(назад к описанию теста)
3.4 VDbench - 4k - 80% rng - 50/50 r/w
(назад к оглавлению)
(назад к описанию теста)
3.5 VDbench - 64k - 80% rng - 75/25 r/w
(назад к оглавлению)
(назад к описанию теста)
3.6 VDbench - 8k - 80% rng - 75/25 r/w
(назад к оглавлению)
(назад к описанию теста)
3.7 FIO - 256k - 0% rng - 0/100 r/w
(назад к оглавлению)
(назад к описанию теста)
3.8 FIO - 4k - 100% rng - 100/0 r/w
(назад к оглавлению)
(назад к описанию теста)
3.9 FIO - 4k - 100% rng - 70/30 r/w
(назад к оглавлению)
(назад к описанию теста)
3.10 FIO - 8k - 100% rng 70/30 r/w
(назад к оглавлению)
(назад к описанию теста)
3.11 Сравнение софт рейдов
3.11.1 Raid0
Итогом стало лидерство LVM в тестах где нагрузка идёт в рамках пары дисков (vdbench) и аналогичное по % лидерство mdadm в тестах где есть множество дисков (8 штук). Также стоит отметить тот факт, что отключение Checksum даёт следующий прирост для производительности ZFS (порядка ~22%):
3.11.2 Raid5
4. NVMe-oF
4.1 Проблемы Next-Next-Next для NVMe-oF
При простом включении NVMe-oF (включая настройки тут, тут и тут) и SPDK в начале всё работало, но в ходе тестов начала проявляться значительная деградация, вплоть до того, что датастор открывался по 5-12 секунд, при простом копировании ВМок производительности других ВМ падала в 0 (именно в 0, т.е. IO вообще не проходили), а в логах сыпалось:
2025-05-17T19:17:46.535Z warning hostd[2099859] [Originator@6876 sub=IoTracker] In thread 2099865, open("/vmfs/volumes/6828d6a7-6e0bb546-8c25-ac1f6be8140e/hci-fio-datastore-6001-1-4/hci-fio-datastore-6001-1-4_1.vmdk~") took over 5 sec.
А средний отклик IO достигал вплоть до 9 секунд судя по графикам.
В ходе изучения всех возможных настроек производительности для выхода из этой ситуации нашлись следующие настройки, помимо настроек BIOS обозначенных выше.
Для настроек самой CX4:
/opt/mellanox/bin/mlxconfig -d mt4115_pciconf0 set LLDP_NB_DCBX_P1=1 LLDP_NB_TX_MODE_P1=2 LLDP_NB_RX_MODE_P1=2 LLDP_NB_DCBX_P2=1 LLDP_NB_TX_MODE_P2=2 LLDP_NB_RX_MODE_P2=2 CNP_DSCP_P1=48 CNP_802P_PRIO_P1=6 CNP_DSCP_P2=48 CNP_802P_PRIO_P2=6
Для ESXi финальными настройками стало:
esxcli system module parameters set -m nmlx5_core -p "pfctx=0x08 pfcrx=0x08 dcbx=2 trust_state=2 DRSS=4 RSS=8 GEN_RSS=3 max_queues=32 dropless_rq=1"
esxcli system module parameters set -m nmlx5_rdma -p "dscp_force=26 pcp_force=3 roce_version=2"
esxcli network nic ring current set -n vmnicX -r 8192 -t 8192
Полная резервация частоты для ВМ с дисками и повышение Shares до High.
Для Linux внутри ВМ финальной настройкой стало:
Скрипт запуска SPDK таргета (part 1)
#!/bin/bash
mst start
tc_wrap.py -i ens257f0np0
mlnx_qos -i ens257f0np0 --cable_len=1
mlnx_qos -i ens257f0np0 --trust pcp
mlnx_qos -i ens257f0np0 --pfc 0,0,0,1,0,0,0,0
mkdir -p /sys/kernel/config/rdma_cm/mlx5_0
sysctl -w net.ipv4.tcp_ecn=1
echo 6 > /sys/class/net/ens257f0np0/ecn/roce_np/cnp_802p_prio
echo 106 | sudo tee /sys/class/infiniband/mlx5_0/tc/1/traffic_class
cma_roce_tos -d mlx5_0 -t 106
ip link set ens257f0np0.101 type vlan egress-qos-map 4:3
ip link set ens257f0np0.102 type vlan egress-qos-map 4:3
ip link set ens257f0np0.103 type vlan egress-qos-map 4:3
sysctl -w net.core.netdev_budget=600
sysctl -w net.core.rmem_max=16777216
sysctl -w net.ipv4.tcp_rmem=“16384 349520 16777216”
sysctl -w net.ipv4.tcp_congestion_control=cubic
sysctl -w net.core.netdev_budget_usecs=4000
ethtool -G ens257f0np0 rx 8192 tx 8192
mlnx_qos -i ens257f0np0 --tsa=ets,ets,ets,ets,ets,ets,ets,ets --tcbw=0,0,0,100,0,0,0,0
Что удивительно, но даже в случае виртуализации Ubuntu считала что у процессора есть 8 C-state и пыталась их использовать, поэтому их тоже пришлось выключить:
GRUB_CMDLINE_LINUX_DEFAULT="mitigations=off processor.max_cstate=0 default_hugepagesz=1G hugepagesz=1G"
Для SPDK настройками запуска стало:
Скрипт запуска SPDK таргета (part 2)
PCI_ALLOWED=“none” HUGEMEM=40960 /home/storage/spdk/scripts/setup.sh
/home/storage/spdk/build/bin/nvmf_tgt -m 0x3F -s 40G --wait-for-rpc &
sleep 10
/home/storage/spdk/scripts/rpc.py log_set_level DEBUG
/home/storage/spdk/scripts/rpc.py log_set_print_level DEBUG
/home/storage/spdk/scripts/rpc.py iobuf_set_options --small-pool-count 8192 --large-pool-count 4096
/home/storage/spdk/scripts/rpc.py framework_start_init
/home/storage/spdk/scripts/rpc.py nvmf_create_transport -t RDMA -u 16384 -i 131072 -c 8192 -m 127 -q 4096 --acceptor-poll-rate 100
/home/storage/spdk/scripts/rpc.py bdev_aio_create /dev/nvme/nvme_stripe nvme_spdk --fallocate
/home/storage/spdk/scripts/rpc.py nvmf_create_subsystem nqn.2024-05.io.spdk:cnode1 -a -s SPDK00 -d SPDK
/home/storage/spdk/scripts/rpc.py nvmf_subsystem_add_ns nqn.2024-05.io.spdk:cnode1 nvme_spdk
Со стороны Mikrotik настройки в целом в сооветствии со статьёй с одним исключением. На уровне буфферов выстановлены следущие настройки:
Благодаря этому получилось полностью избавить от дропов (до этого при тестах на последотельную запись были дропы пакетов)
4.2 Raw Data
MDADM Raid0
| MDADM Raid0 | |||
NVMe-oF | IOPS | Bandwidth [MB/s] | CPU util [%] | latency [ms] |
VDbench - 4k - 100% rng - 100% Write - 4 thread per disk | 450 770.63 | 1 760.82 | 8.81% | 0.10 |
VDbench - 4k - 100% rng - 100% read - 4 thread per disk | 321 877.10 | 1 257.33 | 10.61% | 0.15 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE | 375 080.07 | 1 465.17 | 12.50% | 0.10 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ | 0.15 | |||
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE | 88 269.87 | 5 516.88 | 13.67% | 0.46 |
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ | 0.58 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE | 329 445.77 | 2 573.80 | 15.41% | 0.10 |
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ | 0.16 | |||
Последовательная запись 256к | 22 864.93 | 5 715.50 | 6.75% | 2.21 |
Случайное 100% чтение 4k | 488 403.93 | 1 907.25 | 12.70% | 0.40 |
Случайное 70% чтение 30% запись 4k WRITE | 486 361.39 | 1 899.50 | 18.49% | 0.36 |
Случайное 70% чтение 30% запись 4k READ | 0.41 | |||
Случайное 70% чтение 30% записи 8к WRITE | 473 253.78 | 3 696.75 | 23.63% | 0.39 |
Случайное 70% чтение 30% записи 8к READ | 0.42 | |||
MDADM Raid5
| MDADM Raid5 | |||
NVMe-oF | IOPS | Bandwidth [MB/s] | CPU util [%] | latency [ms] |
VDbench - 4k - 100% rng - 100% Write - 4 thread per disk | 60 531.05 | 236.44 | 8.45% | 0.82 |
VDbench - 4k - 100% rng - 100% read - 4 thread per disk | 308 500.73 | 1 205.08 | 9.89% | 0.16 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE | 102 964.75 | 402.21 | 11.13% | 0.69 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ | 0.24 | |||
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE | 21 025.80 | 1 314.11 | 12.02% | 7.65 |
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ | 0.49 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE | 110 443.53 | 862.85 | 13.22% | 0.98 |
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ | 0.25 | |||
Последовательная запись 256к | 1398.76 | 349.00 | 7.77% | 35.52 |
Случайное 100% чтение 4k | 477 304.20 | 1 864.00 | 12.79% | 0.41 |
Случайное 70% чтение 30% запись 4k WRITE | 176 430.51 | 688.75 | 14.99% | 1.95 |
Случайное 70% чтение 30% запись 4k READ | 0.73 | |||
Случайное 70% чтение 30% записи 8к WRITE | 61 383.76 | 479.25 | 15.81% | 4.50 |
Случайное 70% чтение 30% записи 8к READ | 1.83 | |||
LVM Raid0
| LVM Raid0 | |||
NVMe-oF | IOPS | Bandwidth [MB/s] | CPU util [%] | latency [ms] |
VDbench - 4k - 100% rng - 100% Write - 4 thread per disk | 459 686.88 | 1 795.65 | 17.01% | 0.10 |
VDbench - 4k - 100% rng - 100% read - 4 thread per disk | 325 189.12 | 1 270.27 | 18.50% | 0.15 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE | 374 578.24 | 1 463.19 | 20.74% | 0.10 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ | 0.15 | |||
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE | 90 484.62 | 5 655.28 | 22.08% | 0.47 |
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ | 0.58 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE | 328 563.80 | 2 566.91 | 24.30% | 0.10 |
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ | 0.16 | |||
Последовательная запись 256к | 21 587.40 | 5396.40 | 10.48% | 2.28 |
Случайное 100% чтение 4k | 485 780.49 | 1 897.20 | 14.57% | 0.40 |
Случайное 70% чтение 30% запись 4k WRITE | 473 075.11 | 1 847.40 | 18.85% | 0.37 |
Случайное 70% чтение 30% запись 4k READ | 0.42 | |||
Случайное 70% чтение 30% записи 8к WRITE | 456 659.78 | 3 567.00 | 23.51% | 0.40 |
Случайное 70% чтение 30% записи 8к READ | 0.44 | |||
LVM Raid5
| LVM Raid5 | |||
NVMe-oF | IOPS | Bandwidth [MB/s] | CPU load [%] | latency [ms] |
VDbench - 4k - 100% rng - 100% Write - 4 thread per disk | 79463.13 | 310.40 | 12.51% | 0.60 |
VDbench - 4k - 100% rng - 100% read - 4 thread per disk | 290 190.37 | 1133.56 | 14.09% | 0.16 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE | 135 977.73 | 531.17 | 14.85% | 0.55 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ | 0.16 | |||
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE | 32 461.10 | 2 028.82 | 16.05% | 4.98 |
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ | 0.31 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE | 153 652.13 | 1 200.41 | 17.87% | 0.75 |
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ | 0.17 | |||
Последовательная запись 256к | 2 291.33 | 572.67 | 3.13% | 22.19 |
Случайное 100% чтение 4k | 181 423.16 | 708.00 | 4.63% | 1.06 |
Случайное 70% чтение 30% запись 4k WRITE | 124 911.17 | 487.00 | 6.03% | 1.61 |
Случайное 70% чтение 30% запись 4k READ | 1.50 | |||
Случайное 70% чтение 30% записи 8к WRITE | 87 156.36 | 680.67 | 7.23% | 3.12 |
Случайное 70% чтение 30% записи 8к READ | 1.28 | |||
ZFS Stripe (Raid0)
| ZFS Stripe | |||
NVMe-oF | IOPS | Bandwidth [MB/s] | CPU util [%] | latency [ms] |
VDbench - 4k - 100% rng - 100% Write - 4 thread per disk | 15 179.28 | 59.29 | 9.84% | 3.16 |
VDbench - 4k - 100% rng - 100% read - 4 thread per disk | 72 292.00 | 282.39 | 11.32% | 0.66 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE | 28 532.58 | 111.46 | 13.08% | 1.73 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ | 1.63 | |||
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE | 19 079.55 | 1192.47 | 14.85% | 1.82 |
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ | 2.74 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE | 38 681.13 | 302.20 | 16.68% | 1.26 |
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ | 1.23 | |||
Последовательная запись 256к | 4 202.06 | 1 050.00 | 6.96% | 12.00 |
Случайное 100% чтение 4k | 78 842.56 | 307.50 | 8.50% | 2.45 |
Случайное 70% чтение 30% запись 4k WRITE | 38 714.70 | 150.75 | 9.67% | 5.04 |
Случайное 70% чтение 30% запись 4k READ | 4.96 | |||
Случайное 70% чтение 30% записи 8к WRITE | 28 630.00 | 223.25 | 10.52% | 7.05 |
Случайное 70% чтение 30% записи 8к READ | 6.43 | |||
ZFS RaidZ (Raid5)
| ZFS RaidZ | |||
NVMe-oF | IOPS | Bandwidth [MB/s] | CPU util [%] | latency [ms] |
VDbench - 4k - 100% rng - 100% Write - 4 thread per disk | 12 260.97 | 47.89 | 12.48% | 3.91 |
VDbench - 4k - 100% rng - 100% read - 4 thread per disk | 57 072.60 | 222.94 | 13.27% | 0.84 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk WRITE | 22 959.23 | 89.68 | 13.98% | 2.14 |
VDbench - 4k - 80% rng - 50/50 r/w - 4 thread per disk READ | 2.06 | |||
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk WRITE | 14 061.90 | 878.87 | 14.85% | 2.13 |
VDbench - 64k - 80% seq - 75/25 r/w - 4 thread per disk READ | 3.84 | |||
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk WRITE | 30 963.83 | 241.91 | 16.65% | 1.58 |
VDbench - 8k - 80% rng - 75/25 r/w - 4 thread per disk READ | 1.54 | |||
Последовательная запись 256к | 2 928.63 | 731.50 | 7.65% | 16.96 |
Случайное 100% чтение 4k | 61 621.75 | 240.50 | 8.61% | 3.13 |
Случайное 70% чтение 30% запись 4k WRITE | 30 315.13 | 118.00 | 9.56% | 6.48 |
Случайное 70% чтение 30% запись 4k READ | 6.38 | |||
Случайное 70% чтение 30% записи 8к WRITE | 22 773.56 | 177.50 | 10.24% | 9.23 |
Случайное 70% чтение 30% записи 8к READ | 8.16 | |||
4.3 VDbench - 4k - 100% rng - 100% Write
(назад к оглавлению)
(назад к описанию теста)
4.4 VDbench - 4k - 100% rng - 100% read
(назад к оглавлению)
(назад к описанию теста)
4.5 VDbench - 4k - 80% rng - 50/50 r/w
(назад к оглавлению)
(назад к описанию теста)
4.6 VDbench - 64k - 80% rng - 75/25 r/w
(назад к оглавлению)
(назад к описанию теста)
Вот тут наглядно видно, что mdadm не хватает ядер учитывая, что таргет NVMe скушал практически всё себе. LVM тоже не очень хорошо, даже с учётом всех особых условий
4.7 VDbench - 8k - 80% rng - 75/25 r/w
(назад к оглавлению)
(назад к описанию теста)
4.8 FIO - 256k - 0% rng - 0/100 r/w
(назад к оглавлению)
(назад к описанию теста)
Ситуация схожа с 64k тестом, опять же mdadm не хватает CPU, но в отличии от LVM - он не ломает таргет, поэтому послабления не получил. Но ZFS конечно на последовательной записи большим асинхронным блоком в режиме рейда лидер, в конце концов ему достаточно положить блок в память, чтобы быть готовым принять следующим, в то время как mdadm и lvm прежде чем писать дальше нужно сперва записать предыдующий блок.
4.9 FIO - 4k - 100% rng - 100/0 r/w
(назад к оглавлению)
(назад к описанию теста)
4.10 FIO - 4k - 100% rng - 70/30 r/w
(назад к оглавлению)
(назад к описанию теста)
4.11 FIO - 8k - 100% rng 70/30 r/w
(назад к оглавлению)
(назад к описанию теста)
4.12 Сравнение софт рейдов
4.12.1 Raid 0
4.12.2 Raid 5
Вывод
mdadm показывает себя в Raid5 (если ему дать послабления в NVMe-oF как для ZFS), LVM в raid0. ZFS ваш выбор если у вас ВСЯ нагрузка это много-много асинхронного чтения\записи блоками по 64+кб.
Графическое представление NVMe-oF vs iSER
Зелёный - NVMe-oF
Бордовый - iSER
mdadm Raid0
Значения как и ожидались, NVMe-oF показывает результаты лучше по всем тестам, кроме mix r/w большим блоком, где показывается паритет
mdadm Raid5
Даже не смотря на нехватку ресурсов - mdadm с nvme-of всё ещё прекрасно себя чувствует в половине тестов.
LVM Raid0
Из интересной аномалии тут это не паритет 64кб операции, но он объясняется тем, что в случае с NVMe-oF у нас оставалась высокая задержка на запись 64кб блоком при одновременном чтении.
LVM Raid5
LVM с учётом особых условий демонстрирует ожидаемый эффект от NVMe-oF по всем тестам,
ZFS Stripe (Raid0)
С ZFS картина конечно сильно печальней, для сочетания NVMe-oF и ZFS однозначно нужен отдельный хост, потому что что таргет, что ZFS насилуют CPU только так. Количество ядер надо брать по количеству NVMe дисков + ещё нужно на таргет количество хостов / 2 округленное в большую сторону. Т.е. для 3 хостов минимум 2 ядра, для 5 - 3 ядра, и т.д.
ZFS RaidZ (Raid5)
Картина аналогичная Stripe, то так как RaidZ ещё более CPU intensive - iSER показывает однозначный выигрыш.
Итоговая картина NVMe-oF vs iSER с цветовой гаммой выглядит следующим образом, в ней показатели NVMe-oF поделены на iSER.
В столбце IOPS, если NVMe-oF / iSER >= 1, то это зелёный цвет (мы получили больше IOPS на NVMe-oF), в противном случае оттенок коричневого
В столбце Latency, если NVMe-oF / iSER <= 1, то это зелёный цвет (мы получили задержку ниже при использовании NVMe-oF), в противном случае оттенок коричневого
В столбце CPU Load, если NVMe-oF / iSER <= 1, то это зелёный цвет (мы получили показатели CPU USED на уровне кластера ниже при использовании NVMe-oF), в противном случае оттенок коричневого
Почему мы проигрываем по CPU, когда основная задача NVMe-oF разгрузить CPU? Потому что таргет SPDK работает по пуллинг механизму, а значит он работает всегда на 100% всех ядер, которые ему отдали, а CPU load указан для всего кластера, а не только для ВМ-ок. Если выносить SPDK на отдельную физическую машину, то CPU load тоже будет в зелёной зоне:
И в случае ZFS есть не менее интересный нюанс. Из-за того, что SPDK всегда использует, ядра что ему выдали на 100% - ZFS банально не хватает CPU на то, чтобы выполнить свои операции, из-за чего мы практически всегда проигрываем iSER таргету в ядре. Аналогичная ситуация с mdadm в рейде, но в отличии от ZFS ему не было послаблений в лице более жирной ВМ.
5) Update 1. ZFS compression
Относительно ZFS и оставленной компрессии по умолчанию:
Отключение компрессии привело к следующим результатам, которые ложатся в 5% погрешность для большей части тестов по IOPS и latency, а вот по CPU load выигрыш получился приличный для последовательного записи и чтения в тестах FIO, где генерируемые данные имели параметр buffer_compress_percentage=50. В таблице сооветственно значения ZFS noLZ4 делённые на ZFS lz4 (табличные данные приведены в общей таблице) при подключение через iSER.
