ZFS Mirror - Probleme mit I/O Delay

Shagnar

Member
Sep 14, 2012
6
0
21
Hallo,

ich nutze Proxmox seit vielen Jahren für meinen Homeserver. Da der Server inzwischen wichtige Aufgaben übernimmt, habe ich ihn mit ECC-fähiger-Hardware (Core i3-9100F, 64GB ECC RAM, Supermicro X11 Board) ausgestattet und bin von einer Single-Consumer-SSD (Samsung 830) für Host+VMs umgestiegen auf zwei Consumer-SSDs (Samsung 830, Crucial M4) als ZFS-Mirror mit ashift=12 ("rpool").

Außerdem gibt es im System noch ein Raidz2 bestehend aus 4x 8TB HDDs.

Ich habe nun das Problem, dass der ZFS Mirror Pool bei hoher Auslastung das komplette System lahm legt. Das tritt z.B. auf, wenn ich ein Restore einer VM (Source: Raidz2, gzip - daher eher Limitierung durch die CPU erwartet) ausführe oder auch nur in einer VM den ungenutzten Speicherplatz mittels dd nulle. Mit "lahm legt" meine ich, das keine der VMs mehr reagiert bzw. ansprechbar ist, sobald rpool intensiv genutzt wird. Auch die auf diesen VMs laufenden Services sind dann nichtmehr ansprechbar. Selbst die PVE-Webgui ist de facto unbenutzbar und hat später z.T. auch Aussetzer in der Statistik.

Auf dem Host entstehen dabei Load-Werte von knapp unter 100 und entsprechendes IO delay:
Annotation 2019-12-17 220718.pngAnnotation 2019-12-17 220746.png

Ashift=12 hatte mir der Installer vorgeschlagen.
Über https://github.com/zfsonlinux/zfs/issues/6373 bin ich auf die stelle im zfs on linux code gestoßen, indem die korrekte sektorgröße manuell beschrieben wird:
https://github.com/zfsonlinux/zfs/b...72de03a1257e899c5/cmd/zpool/zpool_vdev.c#L107 - 8KB oder eben ashift=13.

Bevor ich das System mit ashift=13 neu aufsetze möchte ich nach Möglichkeit verifizieren, dass dies auch der Grund des Problems ist. Da ich zuvor eine einzelne SSD mit EXT4 und einer Blocksize von 4KB genutzt habe, ohne Probleme mit der Performance zu haben, zweifle ich daran etwas.

Ich bin über jeden Tipp/Hilfe dankbar. Selbst wenn ein unglückliches Ashift dazu führt, dass die SSDs jedes Write doppelt ausführen müssen, dürfte doch hohe IO nicht gleich das ganze System ausknocken...?

rpool:
NAME USED AVAIL REFER MOUNTPOINT
rpool 108G 120G 96K /rpool
rpool/ROOT 1.57G 120G 96K /rpool/ROOT
rpool/ROOT/pve-1 1.57G 120G 1.57G /
rpool/data 107G 120G 96K /rpool/data
rpool/data/vm-100-disk-0 1.25G 120G 1.25G -
rpool/data/vm-101-disk-0 5.90G 120G 5.90G -
rpool/data/vm-102-disk-0 1.15G 120G 1.15G -
rpool/data/vm-104-disk-0 3.79G 120G 3.79G -
rpool/data/vm-107-disk-0 2.70G 120G 2.70G -
rpool/data/vm-107-disk-1 38.5G 120G 38.5G -
rpool/data/vm-108-disk-0 8.02G 120G 8.02G -
rpool/data/vm-200-disk-0 18.6G 120G 18.6G -
rpool/data/vm-201-disk-0 25.7G 120G 25.7G -
rpool/data/vm-300-disk-0 1.18G 120G 1.18G -
NAME PROPERTY VALUE SOURCE
rpool type filesystem -
rpool creation Fri Dec 13 23:25 2019 -
rpool used 108G -
rpool available 120G -
rpool referenced 96K -
rpool compressratio 1.20x -
rpool mounted yes -
rpool quota none default
rpool reservation none default
rpool recordsize 128K default
rpool mountpoint /rpool default
rpool sharenfs off default
rpool checksum on default
rpool compression lz4 local
rpool atime off local
rpool devices on default
rpool exec on default
rpool setuid on default
rpool readonly off default
rpool zoned off default
rpool snapdir hidden default
rpool aclinherit restricted default
rpool createtxg 1 -
rpool canmount on default
rpool xattr sa local
rpool copies 1 default
rpool version 5 -
rpool utf8only off -
rpool normalization none -
rpool casesensitivity sensitive -
rpool vscan off default
rpool nbmand off default
rpool sharesmb off default
rpool refquota none default
rpool refreservation none default
rpool guid 13966561220250899902 -
rpool primarycache all default
rpool secondarycache all default
rpool usedbysnapshots 0B -
rpool usedbydataset 96K -
rpool usedbychildren 108G -
rpool usedbyrefreservation 0B -
rpool logbias latency default
rpool objsetid 54 -
rpool dedup off default
rpool mlslabel none default
rpool sync standard local
rpool dnodesize legacy default
rpool refcompressratio 1.00x -
rpool written 96K -
rpool logicalused 130G -
rpool logicalreferenced 42K -
rpool volmode default default
rpool filesystem_limit none default
rpool snapshot_limit none default
rpool filesystem_count none default
rpool snapshot_count none default
rpool snapdev hidden default
rpool acltype off default
rpool context none default
rpool fscontext none default
rpool defcontext none default
rpool rootcontext none default
rpool relatime off default
rpool redundant_metadata all default
rpool overlay off default
rpool encryption off default
rpool keylocation none default
rpool keyformat none default
rpool pbkdf2iters 0 default
rpool special_small_blocks 0 default

pve:
CPU BOGOMIPS: 28800.00
REGEX/SECOND: 4273105
HD SIZE: 120.29 GB (rpool)
FSYNCS/SECOND: 285.84
DNS EXT: 22.69 ms
DNS INT: 1.30 ms (fritz.box)
proxmox-ve: 6.1-2 (running kernel: 5.3.13-1-pve)
pve-manager: 6.1-3 (running version: 6.1-3/37248ce6)
pve-kernel-5.3: 6.1-1
pve-kernel-helper: 6.1-1
pve-kernel-5.3.13-1-pve: 5.3.13-1
pve-kernel-5.3.10-1-pve: 5.3.10-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.2-pve4
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.13-pve1
libpve-access-control: 6.0-5
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-9
libpve-guest-common-perl: 3.0-3
libpve-http-server-perl: 3.0-3
libpve-storage-perl: 6.1-2
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve3
lxc-pve: 3.2.1-1
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.1-1
pve-cluster: 6.1-2
pve-container: 3.0-14
pve-docs: 6.1-3
pve-edk2-firmware: 2.20191127-1
pve-firewall: 4.0-9
pve-firmware: 3.0-4
pve-ha-manager: 3.0-8
pve-i18n: 2.0-3
pve-qemu-kvm: 4.1.1-2
pve-xtermjs: 3.13.2-1
qemu-server: 6.1-3
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.2-pve2

Edit: Arcstats
c_min 4 8589934592
c_max 4 34359738368
arc_no_grow 4 0
arc_tempreserve 4 0
arc_loaned_bytes 4 0
arc_prune 4 0
arc_meta_used 4 944149464
arc_meta_limit 4 25769803776
arc_dnode_limit 4 2576980377
arc_meta_max 4 3487913472
arc_meta_min 4 16777216
async_upgrade_sync 4 105754
arc_need_free 4 0
arc_sys_free 4 1052261056
arc_raw_size 4 0
 
Last edited:
Ich habe das System heute mit ashift=13 neu aufgesetzt. Es ist auf jeden Fall besser (weniger "Blockade" unter Last) als mit ashift=12. Ich habe testweise gleichzeitig ein großes (~30GB) Image wiederhergestellt und in einer VM Die VHD komplett ausgelastet. Es wurde auch Laggy, aber nie so, dass Logeinträge verloren gingen oder VMs abgestürzt sind. Immerhin also eine Signifikante Verbesserung.

Ich überlege jetzt statt der Consumer SSDs eine Enterprise SSD einzubauen. (Ausgesucht hatte ich mir diese hier mit Power Loss Protection: https://geizhals.de/micron-5200-eco-480gb-mtfddak480tdc-1at1zabyy-a1774799.html

Was ist besser bei einer SSD - LVM Thin+Ext4 oder Single Drive ZFS?

Hier noch die Benchmark-Ergebnisse (fio mittels https://github.com/rsyring/disk-bench):
Code:
ashift=12
╭──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────╮
│ Stats (MB/s) │   seqread    │   randread   │  4kQD32read  │  4kQD16read  │   seqwrite   │  randwrite   │ 4kQD32write  │ 4kQD16write  │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│              │        777.2 │        136.9 │        275.9 │         14.1 │        187.1 │        358.6 │          7.2 │          7.6 │
╰──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────╯

ashift=13
╭──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────╮
│ Stats (MB/s) │   seqread    │   randread   │  4kQD32read  │  4kQD16read  │   seqwrite   │  randwrite   │ 4kQD32write  │ 4kQD16write  │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│              │        877.5 │        256.6 │        169.4 │         21.0 │        237.2 │        818.4 │          9.5 │         11.3 │
╰──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────╯
╭──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────┬──────────────╮
│ Stats (MB/s) │   seqread    │   randread   │  4kQD32read  │  4kQD16read  │   seqwrite   │  randwrite   │ 4kQD32write  │ 4kQD16write  │
├──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│              │        773.4 │        183.8 │        223.5 │         23.0 │        219.0 │        410.3 │         11.7 │         12.4 │
╰──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────╯
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!