Dotaz: Nízký výkon ZFS při čtení mirrored NVME disků

[v.]

Na posledním proxmoxu VE (debian) mám 2 serverové micron NVME pcie disky v zfs mirroru, ashift 12 (s 13 se to chová v podstatě stejně), bez komprese. Pokud na jednom z disků vytvořím XFS, tak přes fio dostanu něco přes 300k IOPS zápis, přes 800k IOPS čtení. To beru jako referenční hodnoty.

Nicméně v ZFS mirroru dostanu také přes 300K IOPS zápis, ale čtení jen kolem 200k IOPS. To je 4x méně než na XFS na jednom disku. Zkoušel jsem vypnout cache (v tom případě spadne čtení až na 20k), vypnout checksumy (bez efektu). Problém vidím v tom, že při testování přes fio je CPU hodně saturován (až na 100%] a zvýšení numjobs to spíš zhorší (více CPU využitých na 100 procent při nižším výkonu ... nechápu). Dokázal by mi někdo, kdo má větší znalosti ZFS vysvětlit dané chování? Díky.

IOPS testování pomocí:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=fiotest --bs=4k --iodepth=32 --size=8G -numjobs=20 --readwrite=randwrite

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=4k --iodepth=256 --size=8G --numjobs=20 --readwrite=randread

Odpovědi

[z_sk]

Rob9 to aj vtedy, keď celý odiel je vo RAMFS?

[v.]

Když vytvořím zfs mirror na /dev/ram0 a /dev/ram1, pak se to chová jinak a je to pomalejší. Při testování se CPU "fláká", ale max. IOPS při zápisu je 52k, při čtení 152k. Na tyto hodnoty se to dostane okamžitě a je to nějaký strop něčeho, nevím čeho.

[PetebLazar]

O jaký model SSD jde konkrétně?

Byla mezi testy zápisu a čtení dostatečná "relaxační prodleva"?

Byl v době zahájení testů XFS/ZFS volný prostor TRIMovaný?

[v.]

Micron_7450. Netrimoval jsem, jsou to 6TB nové disky. I když jsem testoval jen zápis, chovalo se to stejně, takže nezávisle na prodlevě.

[PetebLazar]

Tak jsem zkusil pro zajímavost ten rndread na svém RAID0(ext4) ze 4x NVMe Samsung 970Pro 1TB (Thr 1950X osazených v PCIe 16x3.0 s bifurkací na čtyři M.2 4x3.0) s výsledkem:

Jobs: 20 (f=20): [r(20)][100.0%][r=8625MiB/s][r=2208k IOPS][eta 00m:00s]

I podle průběžného snímku z iostat 1 to vypadá, že to dělalo 2208 ktps

Device        tps         kB_read/s      kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
md0           2208591,00   8834368,00         0,00         0,00    8834368          0          0
nvme1n1       551242,00   2204968,00         0,00         0,00    2204968          0          0
nvme2n1       552301,00   2209200,00         0,00         0,00    2209200          0          0
nvme3n1       552643,00   2210564,00         0,00         0,00    2210564          0          0
nvme4n1       552201,00   2208804,00         0,00         0,00    2208804          0          0

Test zápisu na tom byl hůře, ale díky přímému zápisu do MLC-2bit (bez pseudo-SLC cache) by měl být předvídatelnější. V trvalém sekvenčním zápisu by měl být stropem jednotlivého SSD cca 2,6GB/s, ale k tomu jsem se díky dnes již limitovaného výkonu stroje z 2017/9 nepřiblížil.

Jobs: 19 (f=17): [w(1),_(1),w(11),f(1),w(1),f(1),w(4)][96.0%][w=6686MiB/s][w=1712k IOPS][eta 00m:01s]

Device        tps           kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
md0           1714455,00         0,00   6857820,00         0,00          0    6857820          0
nvme1n1       428542,00         0,00   1714168,00         0,00          0    1714168          0
nvme2n1       427347,00         0,00   1709384,00         0,00          0    1709384          0
nvme3n1       429390,00         0,00   1717556,00         0,00          0    1717556          0
nvme4n1       429205,00         0,00   1716820,00         0,00          0    1716820          0

[v.]

Při testování čtení mi iostat ukazuje toto:

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
dm-0              0.00         0.00         0.00         0.00          0          0          0
dm-1              0.00         0.00         0.00         0.00          0          0          0
dm-2              0.00         0.00         0.00         0.00          0          0          0
dm-3              0.00         0.00         0.00         0.00          0          0          0
dm-4              0.00         0.00         0.00         0.00          0          0          0
nvme0n1           0.00         0.00         0.00         0.00          0          0          0
nvme1n1           0.00         0.00         0.00         0.00          0          0          0
sda               0.00         0.00         0.00         0.00          0          0          0

Vypadá to, že ZFS dává všechno z nějaké RAM cache a vůbec to nesahá na disky...

[PetebLazar]

Vypadá to tak.

Podle specifikací výrobce by ty moje 970Pro jednotlivě měly mít po 500kIOPS pro random R/W, takže ta moje čísla nevypadají úplně mimo.

[copper]

atime je vypnuté?

zfs set atime=off xxxx

[v.]

Měl jsem zapnuté relatime. S atime na off je to jen o kousek rychlejší (o cca 2 procenta).

[ewew]

Čo tam máš za základnú dosku ak existuje ? Môžeš sem vložiť výstup z dmesg ? Ako vyzerá /proc/interrupts ?

Na dosku sa pýtam, pretože mám podozrenie, že tam máš zdielanie IRQ alebo dátových liniek. Dmesg kvôlo celkovej konfigurácii po spustení a /proc/interrupts môžeš skontrolovať ako si cpu rozdelili jednotlivé prerušenia.

Pri testoch si pusti iotopalebo atop.

[v.]

Příloha:

• dmesg_interrupts (415022 bytů)

Je to server ProLiant DL380 Gen10 (868703-B21), lshw identifikuje desku jako "ProLiant DL380 Gen10". dmesg + interrupts v příloze.

[Heretik 《小魔神》]

ZFS kešuje přes RAM velmi silně, by design. (Hlavně proto se doporučuje zásadně ECC.) Příkladem, 8G RAM stroj je v BSD tradičně považován za nedostatečný pro ZFS a je potřeba u takového uměle snížit využití paměti u ZFS vhodnou konfigurací (nebo použít jiný souborový systém). To spolehlivě funguje, kdysi jsem to úspěšně provedl pro nějaký intelský tablet.

Takže třeba oblíbené miniaturní Linuxové virtuální servery s dispozicí okolo 2G RAM se pro vlastní ZFS naprosto nehodí. V BSD se to pro virtuály řeší opačně: zpool běží na hostu a jednotlivé virtuály dostávají delegované datasety přímo od něj. Plný výkon pole v hostu zůstává zachován. Obávám se však, že delegace v Linuxu (stále ještě) nefunguje, alespoň se pamatuji, že dříve v Linuxovém kernelu patřičné bezpečnostní facility pro delegaci mimo root úplně chyběly. Nevím jak dnes. Takže delegace asi není řešení pro ZoL.

Domníval bych se, že někde dochází k serializaci io požadavků. Moje pochybnost by v tomto případě byla namířena spíše na hypervisor. Takové zpomalení čtení je nepřirozené, zpool dokonce umožňuje čtení v mirroru paralelizovat. Asi by bylo užitečné vyloučit problém ZFS jako takového na konkrétních řadičích konkrétního výrobce změřením rychlosti těch disků v syrovém FBSD.

Linuxové kontejnery nepovažuji za cestu, to je kludge.