Proxmox plötzlich sehr langsam

[Don_2020]

Dank. Hier sind die Ergebnisse.

iperf -c 192.168.178.2
------------------------------------------------------------
Client connecting to 192.168.178.2, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.178.33 port 56172 connected with 192.168.178.2 port 5001 (icwnd/mss/irtt=14/1448/92)
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-10.0028 sec 68.7 GBytes 59.0 Gbits/sec

iperf -R -c 192.168.178.2
------------------------------------------------------------
Client connecting to 192.168.178.2, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.178.33 port 49784 connected with 192.168.178.2 port 5001 (reverse) (icwnd/mss/irtt=14/1448/91)
[ ID] Interval Transfer Bandwidth
[ *1] 0.0000-10.0006 sec 73.1 GBytes 62.8 Gbits/sec

iperf --bidi -c 192.168.178.2
iperf: unrecognized option `--bidi'
------------------------------------------------------------
Client connecting to 192.168.178.2, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.178.33 port 60922 connected with 192.168.178.2 port 5001 (icwnd/mss/irtt=14/1448/90)
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-10.0162 sec 71.2 GBytes 61.1 Gbits/sec

 

[qiller]

Top Werte, damit sollte eine irgendwie fehlgeleitete Netzwerkverbindung ausgeschlossen sein. Dann würde ich als nächstes den Storage benchmarken, einmal vom PVE aus, einmal gemountet in der VM. Z.B. einfach mit dd

#Schreiben:
dd if=/dev/random of=/mnt/storage/tmp.dat bs=2048k count=50k

#Schreiben, falls ZFS-Komprimierung deaktiviert (schneller):
dd if=/dev/zero of=/mnt/storage/tmp.dat bs=2048k count=50k

#Lesen:
dd of=/dev/null if=/mnt/storage/tmp.dat bs=2048k count=50k

Damit wird eine 100GiB große Temp-Datei geschrieben und gelesen. /mnt/storage musst du dann entsprechend der Mountpoints anpassen.

Edit: Die tmp.dat kannste im Anschluss auch wieder löschen.

 

[Don_2020]

dd if=/dev/random of=/storage/tmp.dat bs=2048k count=50k
51200+0 records in
51200+0 records out
107374182400 bytes (107 GB, 100 GiB) copied, 326.369 s, 329 MB/s

dd if=/dev/zero of=/storage/tmp.dat bs=2048k count=50k
51200+0 records in
51200+0 records out
107374182400 bytes (107 GB, 100 GiB) copied, 42.8797 s, 2.5 GB/s

dd of=/dev/null if=/storage/tmp.dat bs=2048k count=50k
51200+0 records in
51200+0 records out
107374182400 bytes (107 GB, 100 GiB) copied, 5.46586 s, 19.6 GB/s

Das Problem scheint das Schreiben zu sein.

 

[qiller]

Das sind jetzt Werte aus der VM heraus, wo der Storage per NFS eingebunden ist? Oder direkt auf dem PVE-Host?

 

[Don_2020]

Die Werte sind auf dem Server ermittelt worden.

Ich glaube ich habe den Übertäter gefunden.
zpool status -v
pool: storage
state: ONLINE
scan: scrub in progress since Sun May 11 00:24:01 2025
37.0T / 71.3T scanned at 962M/s, 32.9T / 71.3T issued at 736M/s
0B repaired, 46.17% done, 15:10:28 to go
config:

NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-TOSHIBA_MG10ACA20TE_7360A03QF4MJ ONLINE 0 0 0
ata-TOSHIBA_MG10ACA20TE_7370A05NF4MJ ONLINE 0 0 0
ata-TOSHIBA_MG10ACA20TE_7370A0ZJF4MJ ONLINE 0 0 0
ata-TOSHIBA_MG10ACA20TE_7370A102F4MJ ONLINE 0 0 0

errors: No known data errors

Da läuft also was im Hintergrund. Schade das das nicht von Proxmox direkt angezeigt wird.
Im log gefunden:
May 11 00:24:01 pve1 CRON[3741252]: (root) CMD (if [ $(date +%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ]; then /usr/lib/zfs-linux/scrub; fi)

 

[qiller]

Naja, das ist der normale Scrub für ZFS-Pools. Kenn das nur von unserm TrueNAS mit 4x18TB HDDs und da dauerte der letzte Scrub auch fast 12h. Den sollteste auf ne Zeit/Datum legen, wo der Storage nicht so stark beansprucht wird.

 

[Don_2020]

Das Ding startet um 00:24 un läuft immer noch. Scheint eine Vorgabe von Proxmox zu sein. Läuft jetzt ca. 18 Stunden (Stand 52 %) .

 

[qiller]

Scheint eine Vorgabe von Proxmox zu sein.

Ist es auch, daher gibts ja immer die Empfehlung von den Proxmox-Fachleuten den Scrubjob anzupassen. Auf dem Proxmox, den ich betreue, gibts nur einen einfachen 2TB ZFS-Mirror aus 2x 2TB NVMe Laufwerken und da dauerte der Scrub heute von 00:24 bis 00:36 - also 12 Minuten. Das sieht halt bei nem riesigen 60TB RaidZ1 mit nur 4 HDDs ein bisschen anders aus :x.

 

[GrillSgt]

Scheint eine Vorgabe von Proxmox zu sein.

Sorry, aber das wird nicht das Erste Mal sein, dass das läuft. Das wird regelmäßig ausgeführt. Der Intervall ist in

/etc/cron.d/zfsutils-linux

konfiguriert.