Hallo zusammen,
ich habe ein großes Problem: auf meinem neuen System treten regelmäßig Phantom-Write-I/O Situationen auf, die dazu führen, dass die Disks zu 100% mit Writes ausgelastet werden, deren Ursprung nicht erklärbar ist und das System dadurch derart verlangsamt wird, dass es nur noch bedingt verwendbar, teilweise auch komplett unbenutzbar wird.
Das System ist ein neuer Hexa-Core-Xeon E5-1650 mit 128GB RAM, 2x 2TB SATA Disk und 1x 512GB NVMe. Die SATA-Disks laufen im Mirror und die NVMe als SLOG/L2ARC. Darauf laufen 3 LXC-Container und 6 Qemu-VMs. Das Promox ist up-to-date (pve-perf und weitere Infos: siehe Anhang). Wenn das Problem nicht auftritt, ist der Host flott und das ganze IO läuft sehr flüssig.
Das System wurde Anfang Januar in Betrieb genommen und seither besteht auch das Problem. Ich habe versucht, die Ursache zu finden und ab zu stellen. Das ist final (noch) nicht geglückt, aber ich kann mittlerweile zumindest gewissen Ursachen ausschliessen.
Problembeschreibung
Einflussfaktoren
Auszuschliessende Ursachen
Hat jemand eine Idee, was da los ist?
Habe ich etwas falsch konfiguriert?
Irgendwas mit der Compression?
Dedup ist nicht an.
ashift = 12
Wo kann ich ansetzen, um weiter zu debuggen? Bin mittlerweile recht ratlos.
Ich bin am überlegen, meine Subskription auf Standard hoch zu setzen, so dass der Support sich das mal anschauen kann. Die Frage ist nur: kann der Support bei einem ZFS wirklich helfen?
Gruß
VK
Anhänge
ich habe ein großes Problem: auf meinem neuen System treten regelmäßig Phantom-Write-I/O Situationen auf, die dazu führen, dass die Disks zu 100% mit Writes ausgelastet werden, deren Ursprung nicht erklärbar ist und das System dadurch derart verlangsamt wird, dass es nur noch bedingt verwendbar, teilweise auch komplett unbenutzbar wird.
Das System ist ein neuer Hexa-Core-Xeon E5-1650 mit 128GB RAM, 2x 2TB SATA Disk und 1x 512GB NVMe. Die SATA-Disks laufen im Mirror und die NVMe als SLOG/L2ARC. Darauf laufen 3 LXC-Container und 6 Qemu-VMs. Das Promox ist up-to-date (pve-perf und weitere Infos: siehe Anhang). Wenn das Problem nicht auftritt, ist der Host flott und das ganze IO läuft sehr flüssig.
Das System wurde Anfang Januar in Betrieb genommen und seither besteht auch das Problem. Ich habe versucht, die Ursache zu finden und ab zu stellen. Das ist final (noch) nicht geglückt, aber ich kann mittlerweile zumindest gewissen Ursachen ausschliessen.
Problembeschreibung
- Das Problem tritt sporadisch auf. Je nach organischer (insbesondere vzdump) Last 1-5 mal pro Woche. Es ist kein Muster zu erkennen
- Die IO-Load auf den Disks sba und sdb steigt - gemessen mit atop - auf 100%, weil auf beide Disks bzw. dem mirror geschrieben wird:
- Es ist mit "zpool iostat -v" bzw. "iotop" erkennbar, dass die IO-Load nicht von Container oder VMs kommt. Es ist innerhalb der VMs und Container auch keine IO verursachendes Verhalten zu erkennen. Daher bezeichne ich das ganze als Phantom IO.
- Die massive Auslastung der Disks führt dazu, dass das IO-Wait (IO-Delay) auf 10-15% ansteigt:
- Im Ergebnis ist der Host kaum noch benutzbar, da alles organische IO sehr stark ausgebremst wird.
- In 95% der Fälle verschwindet das Problem nicht von alleine, sondern lässt sich nur durch den Reboot entfernen. In seltenen Fällen geht es von alleine weg - was nicht heisst, dass es "aus dem Nichts" wieder kommt. Siehe hier:
- Ich gehe derzeit davon aus, dass es ein Problem von ZFS ist. Ich habe mal auf https://github.com/zfsonlinux/zfs/issues geschaut: es kommt öfters zu diversen Problemen mit unerklärlichem IO.
Einflussfaktoren
- Serverlast: Das nächtliche Backup aller VMs auf eine Netzwerklaufwerk wurde geändert auf den Dump einer VM pro Tag. Das provoziert den Fehler seltener, er tritt aber noch immer auf. Die hohe Last von vzdump scheint also einen Einfluss zu haben, sie ist aber nicht die Ursache.
Auszuschliessende Ursachen
- SLOG/L2ARC: das Entfernen der NVMe ändert nichts, außer das die organische Performance zurück geht
- vzdump: Die Situation tritt zwar gerne häufig während (und dann anhaltend nach) Backups auf, ein ursächlicher Zusammenhang konnte aber nicht festgestellt werden.
- Der Neustart bzw. das Beenden aller Container und VMs beendet das Problem nicht. Es ist ein Reboot nötig, um das Problem zu heben.
Hat jemand eine Idee, was da los ist?
Habe ich etwas falsch konfiguriert?
Irgendwas mit der Compression?
Dedup ist nicht an.
ashift = 12
Wo kann ich ansetzen, um weiter zu debuggen? Bin mittlerweile recht ratlos.
Ich bin am überlegen, meine Subskription auf Standard hoch zu setzen, so dass der Support sich das mal anschauen kann. Die Frage ist nur: kann der Support bei einem ZFS wirklich helfen?
Gruß
VK
Anhänge
-
-
root@pve1:~$ pveperf
CPU BOGOMIPS: 83797.68
REGEX/SECOND: 2721896
HD SIZE: 1561.77 GB (rpool/ROOT/pve-1)
FSYNCS/SECOND: 98.83
DNS EXT: 12.71 ms
DNS INT: 0.46 ms (kettenbach-it.de) -
Vor dem letzten Kernel Upgrade:
root@pve1:~$ cat /sys/module/zfs/version
0.6.5.8-1
Nach dem letzten Kernel Upgrade:
root@pve1:~$ cat /sys/module/zfs/version
0.6.5.9-1 -
root@pve1:~$ zpool list -v
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 1.81T 229G 1.59T - 11% 12% 1.00x ONLINE -
mirror 1.81T 229G 1.59T - 11% 12%
sda2 - - - - - -
sdb2 - - - - - -
root@pve1:~$ zpool status
pool: rpool
state: ONLINE
scan: scrub repaired 0 in 2h26m with 0 errors on Sun Feb 12 02:50:31 2017
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda2 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
errors: No known data errors
root@pve1:~$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 237G 1.52T 96K /rpool
rpool/ROOT 3.40G 1.52T 96K /rpool/ROOT
rpool/ROOT/pve-1 3.40G 1.52T 3.40G /
rpool/data 225G 1.52T 96K /rpool/data
rpool/data/base-101-disk-1 2.49G 1.52T 2.49G -
rpool/data/subvol-100-disk-1 1.64G 10.4G 1.64G /rpool/data/subvol-100-disk-1
rpool/data/subvol-108-disk-1 2.03G 5.97G 2.03G /rpool/data/subvol-108-disk-1
rpool/data/subvol-109-disk-1 961M 19.1G 961M /rpool/data/subvol-109-disk-1
rpool/data/vm-102-disk-1 3.36G 1.52T 3.36G -
rpool/data/vm-102-disk-2 76.0G 1.52T 76.0G -
rpool/data/vm-103-disk-1 27.3G 1.52T 27.3G -
rpool/data/vm-104-disk-1 19.3G 1.52T 19.3G -
rpool/data/vm-105-disk-1 2.83G 1.52T 2.83G -
rpool/data/vm-106-disk-1 85.5G 1.52T 85.5G -
rpool/data/vm-107-disk-1 3.83G 1.52T 3.83G -
rpool/swap 8.50G 1.53T 629M -
root@pve1:~$ zdb
rpool:
version: 5000
name: 'rpool'
state: 0
txg: 984232
pool_guid: 16272488091660140395
errata: 0
hostid: 2831164162
hostname: 'pve1'
vdev_children: 1
vdev_tree:
type: 'root'
id: 0
guid: 16272488091660140395
children[0]:
type: 'mirror'
id: 0
guid: 17243028066098008388
metaslab_array: 35
metaslab_shift: 34
ashift: 12
asize: 2000384688128
is_log: 0
create_txg: 4
children[0]:
type: 'disk'
id: 0
guid: 956272461755836814
path: '/dev/sda2'
whole_disk: 0
DTL: 108
create_txg: 4
children[1]:
type: 'disk'
id: 1
guid: 16972377322377953413
path: '/dev/sdb2'
whole_disk: 0
DTL: 107
create_txg: 4
features_for_read:
com.delphix:hole_birth
com.delphix:embedded_data