Proxmox laggt

C

chrigiboy

Well-Known Member
Nov 6, 2018
93
1
48
Hallo,
habe nach langer Zeit den Server neu gestartet. Damit wurde wohl auch ein neuer Kernel geladen. Seit dem habe ich nur noch Probleme.
Ich verwende ZFS.
Ich musste, damit ich überhaupt einigermassen schnelle Server habe, bei allen vServer Async IO von io_ring auf threads umstellen und statt IDE HDDS auf Virtio umstellen, andernfalls gab es immer wieder Aussetzer bei den vServer oder eine extrem hohe CPU Load, obwohl nichts lief.

Wenn ich ein Backup auf ein Proxmox Backup Starte, bricht die Geschwindigkeit beim Proxmox zusammen. Ich kann NoVNC nicht mehr öffnen. Das Kopieren des Servers beträgt etwa 1 Mbyte/s und dauert für 1,5 Tbyte entsprechend lange. Die CPU Load des Clientserver schiesst auf 80 hoch (normal 0.3) und ist nur noch träge, das IO Delay des Proxmox Server geht auf 20 hoch. VServer Terminal zeigt dann häufig: soft lock CPU#3 stuck for 26s! oder auch Uhhuh: NMI received for unknown reason 20 on CPU 3. Das hatte ich alles vor dem Neustart nicht. Da lief alles ganz flüssig. Jetzt habe ich auch noch sicherheitshalber auf 8 aktualisiert, aber das Problem besteht weiterhin.
Dann habe ich auch noch die Backup Server aktualisiert. Da habe ich jetzt eine Verbesserung. Normalerweise hatte ich "could not activate storage 'Pxb2': Pxb2: error fetching datastores - 500 read timeout" und ich konnte bei den Clients wenn ich oben rechts den Backupspeicher auswähle, selten die Backupliste laden. Jetzt kommt die Liste sofort.

Hat jemand eine Idee wie ich das wieder in den Griff kriege?

Max Workers habe ich auf 6 gestellt.

-Auch wenn ich das Backup abbreche, bleibt das Backup symbol erhalten, mit qm unlock kriege ich das wieder hin. Danach dauert es etwa 1-2 Stunden und der Server läuft wieder normal. Oft muss ich aber einfach den Server stoppen und dann wieder starten.
- => nano /sys/module/zfs/parameters/zfs_arc_max => 12884901888
- Andere Server die ich nicht neugestartet habe, laufen normal.

Leider habe ich da nicht genau geguckt, was der alte Server hatte. Jetzt läuft 5.15.107-2 und würde heute Nacht noch auf 6 aktualisieren. Und bei den anderen Server läuft aktuell 5.15.85-1 oder 5.4.128-1. Ich vermute, der alte Kernel wird auch irgend eine der beiden Versionen sein.


Jul 10 12:10:07 px20 pvedaemon[3923692]: VM 159 qmp command failed - VM 159 qmp command 'query-proxmox-support' failed - unable to connect to VM 159 qmp socket - timeout after 51 retries
Jul 10 12:10:09 px20 pvedaemon[3923694]: VM 159 qmp command failed - VM 159 qmp command 'guest-ping' failed - got timeout
Jul 10 12:10:10 px20 pvestatd[19727]: VM 159 qmp command failed - VM 159 qmp command 'query-proxmox-support' failed - unable to connect to VM 159 qmp socket - timeout after 51 retries
 
Last edited:
can you post the syslog from both the server and the backup server?
 
Danke für die schnelle Antwort.
Hier die beiden Dateien und noch die Ausgabe vom GUI, ich musste dann aber abbrechen, weil der vServer nicht mehr erreichbar war und auch NoVNC nicht mehr geöffnet werden konnte. Nach den 22Sekunden / 228MByte ging dann eine lange zeit nichts mehr. Normalerweise gibt es mindestens alle paar Sekunden ein Update. Nach ca. 10 Minuten habe ich abgebrochen.



INFO: starting new backup job: vzdump --storage Pxb2 --mailto info@excom.org --notes-template '{{cluster}}, {{guestname}}, {{node}}, {{vmid}}' --all 1 --mode snapshot --prune-backups 'keep-daily=25' --node px20 --exclude 251 --mailnotification failure
INFO: Starting Backup of VM 159 (qemu)
INFO: Backup started at 2023-07-10 09:11:27
INFO: status = running
INFO: VM Name: whmcs
INFO: include disk 'virtio0' 'local:159/vm-159-disk-0.raw' 1500G
INFO: include disk 'virtio1' 'local:159/vm-159-disk-1.raw' 1T
INFO: backup mode: snapshot
INFO: bandwidth limit: 20000 KB/s
INFO: ionice priority: 7
INFO: creating Proxmox Backup Server archive 'vm/159/2023-07-10T07:11:27Z'
INFO: issuing guest-agent 'fs-freeze' command
INFO: issuing guest-agent 'fs-thaw' command
INFO: started backup task '34d302a2-18e6-49af-ae67-40752435fc4b'
INFO: resuming VM again
INFO: virtio0: dirty-bitmap status: created new
INFO: virtio1: dirty-bitmap status: created new
INFO: 0% (228.0 MiB of 2.5 TiB) in 22s, read: 10.4 MiB/s, write: 8.7 MiB/s
ERROR: interrupted by signal
INFO: aborting backup job
 

Attachments

hmmm... dont see any additional information there. can you show the configuration of the vms?

Also please post

pvenode task list --errors --vmid 100
As suggested here ?
 
┌───────────────────────────────────────────────────────────────┬────────────┬─────┬──────────┬────────────┬────────────┬────────┐
│ UPID │ Type │ ID │ User │ Starttime │ Endtime │ Status │
╞═══════════════════════════════════════════════════════════════╪════════════╪═════╪══════════╪════════════╪════════════╪════════╡
│ UPID:px20:00033FAA:0123BCF0:64AA1B0C:vncproxy:159:root@pam: │ vncproxy │ 159 │ root@pam │ 1688869644 │ 1688869650 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:0003852A:0123E084:64AA1B67:vncproxy:159:root@pam: │ vncproxy │ 159 │ root@pam │ 1688869735 │ 1688869741 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:000F7949:011CCE67:64AA094D:qmshutdown:159:root@pam: │ qmshutdown │ 159 │ root@pam │ 1688865101 │ 1688865101 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:000F97FA:011CD6E4:64AA0963:vncproxy:159:root@pam: │ vncproxy │ 159 │ root@pam │ 1688865123 │ 1688865129 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:000FA90A:0029E055:64ABB188:qmconfig:159:root@pam: │ qmconfig │ 159 │ root@pam │ 1688973704 │ 1688973709 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:000FCA5C:0029E8C6:64ABB19D:qmconfig:159:root@pam: │ qmconfig │ 159 │ root@pam │ 1688973725 │ 1688973730 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:00100630:002A00DF:64ABB1DB:qmconfig:159:root@pam: │ qmconfig │ 159 │ root@pam │ 1688973787 │ 1688973792 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:00102CFA:002A0D4F:64ABB1FB:qmconfig:159:root@pam: │ qmconfig │ 159 │ root@pam │ 1688973819 │ 1688973824 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:0010C26B:011CE873:64AA0990:qmstop:159:root@pam: │ qmstop │ 159 │ root@pam │ 1688865168 │ 1688865168 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:0010C410:011CE88B:64AA0990:vncproxy:159:root@pam: │ vncproxy │ 159 │ root@pam │ 1688865168 │ 1688865174 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:00110247:011CED2C:64AA099C:vncproxy:159:root@pam: │ vncproxy │ 159 │ root@pam │ 1688865180 │ 1688865190 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:0017820C:011DBF4A:64AA0BB6:qmshutdown:159:root@pam: │ qmshutdown │ 159 │ root@pam │ 1688865718 │ 1688866318 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:00198D2A:011DED55:64AA0C2C:qmshutdown:159:root@pam: │ qmshutdown │ 159 │ root@pam │ 1688865836 │ 1688865846 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:001B4CE2:011E25DB:64AA0CBD:qmshutdown:159:root@pam: │ qmshutdown │ 159 │ root@pam │ 1688865981 │ 1688865991 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:001D3100:011E4F37:64AA0D26:qmstop:159:root@pam: │ qmstop │ 159 │ root@pam │ 1688866086 │ 1688866096 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:001FDBBF:011E87B4:64AA0DB7:qmstop:159:root@pam: │ qmstop │ 159 │ root@pam │ 1688866231 │ 1688866241 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:001FE49B:011E885C:64AA0DB9:qmshutdown:159:root@pam: │ qmshutdown │ 159 │ root@pam │ 1688866233 │ 1688866243 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:002035B8:011E8E41:64AA0DC8:qmstop:159:root@pam: │ qmstop │ 159 │ root@pam │ 1688866248 │ 1688866258 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:002EF879:01200D9D:64AA119D:qmstart:159:root@pam: │ qmstart │ 159 │ root@pam │ 1688867229 │ 1688867230 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:00303F26:01202F08:64AA11F3:vncproxy:159:root@pam: │ vncproxy │ 159 │ root@pam │ 1688867315 │ 1688867320 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:00328ADF:0120A2A4:64AA131B:qmshutdown:159:root@pam: │ qmshutdown │ 159 │ root@pam │ 1688867611 │ 1688867611 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:0032A0A1:0120A59D:64AA1322:qmstop:159:root@pam: │ qmstop │ 159 │ root@pam │ 1688867618 │ 1688867618 │ ERROR │
├───────────────────────────────────────────────────────────────┼────────────┼─────┼──────────┼────────────┼────────────┼────────┤
│ UPID:px20:003D5400:0121EA19:64AA1661:vncproxy:159:root@pam: │ vncproxy │ 159 │ root@pam │ 1688868449 │ 1688868459 │ ERROR │
└───────────────────────────────────────────────────────────────┴────────────┴─────┴──────────┴────────────┴────────────┴────────┘
 
Also ich habe bei einem Server nach wie vor das Problem, dass ich immer wieder die Konsole nicht öffnen kann.

VM 279 qmp command 'set_password' failed - got timeout
TASK ERROR: Failed to run vncproxy.


Zudem hat der Server eine sehr hohe Load Average von 30.0 obwohl nichts läuft. Auf dem gleichen Proxmox hat es auch noch eine Windows Maschine, dort sind 5 CPU's immer mit 100% am laufen, obwohl nichts läuft.

Beim Linux finde ich immer wieder solche Prozesse:
kworker/u16:3-events_power_efficient

Und oft kommt es zu Unterbüchen von 2-3 Sekunden
Ganz schlimm wird es. wenn folgender Prozess kommt, dann geht gar nichts mehr für 30 Sekunden
kworker/u16:3-events_freezable_power

Was kann man tun? Habe jetzt mal noch auf directsync und Native umgestellt. Ohne Erfolg. Andere Maschinen auf dem selben Server funktionieren soweit normal.
 
Last edited:
Es wird jetzt noch schlimmer. Auf anderen Proxmox Server gibt es plötzlich schwarze Bildschirme der Windows VM und die VM lässt sich anschliessend nicht mehr starten:



TASK ERROR: timeout waiting on systemd


Langsam wird es mit Proxmox echt kritisch!
 
Last edited:
Was für Hardware hat der Server eigentlich? CPU, Arbeitspeicher, Festplatten?

Was gibt denn der Befehl top -b -c -w512 -n 1 -o TIME | head -n 30 aus? Bitte das Ergebnis innerhalb von [CODE][/CODE] Tags posten :)

Schonmal versucht, mit einem älteren Kernel zu starten?
 
Kannst du mal journalctl -b > journal.txt auf beiden hosts ausführen und die Ergebnisshe hier posten

Aus welchen Disken besteht dein RAID? Kannst du mal zpool status posten?
 
aaron said:
Was für Hardware hat der Server eigentlich? CPU, Arbeitspeicher, Festplatten?

Was gibt denn der Befehl top -b -c -w512 -n 1 -o TIME | head -n 30 aus? Bitte das Ergebnis innerhalb von [CODE][/CODE] Tags posten :)

Schonmal versucht, mit einem älteren Kernel zu starten?
Click to expand...


Code: 
top -b -c -w512 -n 1 -o TIME | head -n 30
top - 11:53:36 up 12:17,  1 user,  load average: 15.17, 16.03, 16.83
Tasks: 891 total,   1 running, 890 sleeping,   0 stopped,   0 zombie
%Cpu(s): 16.0 us,  0.8 sy,  0.0 ni, 67.2 id,  1.7 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem : 257593.0 total,  66277.6 free, 192748.4 used,    404.7 buff/cache     
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  64844.6 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  26423 root      20   0   56.3g  48.9g   5120 S 276.5  19.4     24,40 /usr/bin/kvm -id 219 -name sr56.myhost.com,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/219.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/219.pid -daemonize -smbios type=1,uuid=a2b1b571-3705-4e70-bf46-15659ec88e92 -smp 24,sockets=2,cores=12,maxcpus=24 -nodefaul+
  22493 root      20   0   40.3g  31.3g   4608 S  47.1  12.4     14,39 /usr/bin/kvm -id 178 -name sr47.myhost.com,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/178.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/178.pid -daemonize -smbios type=1,uuid=cbf58c35-c26f-41ef-9714-63f3d59c3670 -smp 32,sockets=1,cores=32,maxcpus=32 -nodefaul+
3905715 root      20   0   48.9g  40.1g  14336 S   5.9  16.0      9,44 /usr/bin/kvm -id 249 -name sr55.myhost.com,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/249.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/249.pid -daemonize -smbios type=1,uuid=9c48857d-f867-4488-a58b-ffd618add0a7 -smp 1,sockets=2,cores=12,maxcpus=24 -device ho+
2184667 root      20   0   31.5g  15.7g   6656 S  35.3   6.2      8,23 /usr/bin/kvm -id 159 -name whmcs,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/159.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/159.pid -daemonize -smbios type=1,uuid=aba0a6ae-4c16-43ae-b859-e281ef56fbb6 -smp 20,sockets=1,cores=20,maxcpus=20 -nodefaults -boot men+
1845610 root      20   0   35.1g  31.3g   6656 S 770.6  12.5      6,32 /usr/bin/kvm -id 171 -name sr12.myhost.com,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/171.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/171.pid -daemonize -smbios type=1,uuid=26a28d1c-dcef-4953-b139-bbf67d175268 -smp 8,sockets=1,cores=8,maxcpus=8 -nodefaults +
    410 root      25   5       0      0      0 S  64.7   0.0 258:51.49 [ksmd]
1844261 root      20   0   30.2g  24.5g   7168 S 229.4   9.7  30:56.68 /usr/bin/kvm -id 181 -name sr35.myhost.com,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/181.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/181.pid -daemonize -smbios type=1,uuid=9e1b5e00-d91b-48ce-bce6-8927e08d4281 -smp 8,sockets=1,cores=8,maxcpus=8 -nodefaults +
1804107 root      20   0   38.1g  16.1g   7680 D   5.9   6.4  21:18.10 /usr/bin/kvm -id 279 -name sr1.meine.de,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/279.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/279.pid -daemonize -smbios type=1,uuid=1849dfb8-f2f0-402b-87d1-515aa49562c4 -smp 8,sockets=1,cores=8,maxcpus=8 -nodefaul+
  70682 root      39  19       0      0      0 S   0.0   0.0  14:01.44 [dsl_scan_iss]
  70681 root      39  19       0      0      0 S   0.0   0.0  14:00.37 [dsl_scan_iss]
  20706 root      rt   0  594724 201416  52472 S   5.9   0.1  12:56.11 /usr/sbin/corosync -f
2184769 root      20   0       0      0      0 S   0.0   0.0   9:11.91 [vhost-2184667]
  20739 root      20   0  150548  94904   6144 S   0.0   0.0   8:44.19 pvestatd
   1023 root       0 -20       0      0      0 S   0.0   0.0   8:01.65 [z_rd_int_3]
   1021 root       0 -20       0      0      0 S   0.0   0.0   8:01.45 [z_rd_int_1]
   1026 root       0 -20       0      0      0 S   0.0   0.0   8:01.39 [z_rd_int_6]
   1024 root       0 -20       0      0      0 S   0.0   0.0   8:01.27 [z_rd_int_4]
   1025 root       0 -20       0      0      0 S   0.0   0.0   8:01.26 [z_rd_int_5]
   1020 root       0 -20       0      0      0 S   0.0   0.0   8:01.17 [z_rd_int_0]
   1022 root       0 -20       0      0      0 S   0.0   0.0   8:01.00 [z_rd_int_2]
      2 root      20   0       0      0      0 S   5.9   0.0   6:46.40 [kthreadd]
    409 root      20   0       0      0      0 S   0.0   0.0   6:11.88 [kcompactd0]
   1334 root      20   0       0      0      0 D   0.0   0.0   3:54.82 [txg_sync]
 
Philipp Hufnagl said:
Kannst du mal journalctl -b > journal.txt auf beiden hosts ausführen und die Ergebnisshe hier posten

Aus welchen Disken besteht dein RAID? Kannst du mal zpool status posten?
Click to expand...

Code: 
root@px20:~# zpool status
  pool: rpool
 state: ONLINE
  scan: scrub in progress since Sun Jul  9 00:24:01 2023
        5.94T scanned at 0B/s, 4.68T issued at 110M/s, 6.19T total
        0B repaired, 75.59% done, 03:59:15 to go
config:

        NAME                                                      STATE     READ WRITE CKSUM
        rpool                                                     ONLINE       0     0     0
          mirror-0                                                ONLINE       0     0     0
            nvme-Corsair_MP600_PRO_XT_2221794000013103209B-part3  ONLINE       0     0     0
            nvme-Corsair_MP600_PRO_XT_2204794000013103400D-part3  ONLINE       0     0     0
          mirror-1                                                ONLINE       0     0     0
            nvme-Corsair_MP600_PRO_XT_2131794000013103500C-part3  ONLINE       0     0     0
            nvme-Corsair_MP600_PRO_XT_21317940000131035023-part3  ONLINE       0     0     0

errors: No known data errors


Code: 
root@px21:~# zpool status
no pools available
root@px21:~#

Ich musste die Logfiles kürzes, sonst wären Sie zu gross gewesen. Falls da was wichtiges, fehlt, einfach maledne.
 

Attachments

judging by the errors and kernel traces from your p21.txt output, you system seems to have issues with the hardware. Is there a BIOS update available?

Are you using UEFI? Have you tried it with legacy boot?

Also running a memory test could be a good idea
 
Last edited:
I have moved the VM from px21 to a other Proxmox. That is working.
Memory Test MEMTEST, was OK last night. It is a DELL Server. Selfcheck of HW was also ok.

Currently with the moving of VM the issue on PX21 is fixed. So i still have only issue on px20.
 
p20 as well has over 100 lines in the log reporting problems with your BIOS. Are you sure your installation is fine in this regard?
 
chrigiboy said:
Code: 
root@px20:~# zpool status
  pool: rpool
 state: ONLINE
  scan: scrub in progress since Sun Jul  9 00:24:01 2023
        5.94T scanned at 0B/s, 4.68T issued at 110M/s, 6.19T total
        0B repaired, 75.59% done, 03:59:15 to go
config:

        NAME                                                      STATE     READ WRITE CKSUM
        rpool                                                     ONLINE       0     0     0
          mirror-0                                                ONLINE       0     0     0
            nvme-Corsair_MP600_PRO_XT_2221794000013103209B-part3  ONLINE       0     0     0
            nvme-Corsair_MP600_PRO_XT_2204794000013103400D-part3  ONLINE       0     0     0
          mirror-1                                                ONLINE       0     0     0
            nvme-Corsair_MP600_PRO_XT_2131794000013103500C-part3  ONLINE       0     0     0
            nvme-Corsair_MP600_PRO_XT_21317940000131035023-part3  ONLINE       0     0     0

errors: No known data errors
Click to expand...
Das sind Consumer NVMEs ohne Power Loss Protection. Die sind, wenn sie entsprechend dauerhaft beansprucht werden, mitunter ganz schön langsam. Das Modell kenne ich selber nicht wirklich, deshalb kann ich nicht mehr dazu sagen. Aber folgende Zeile klingt nicht gut:
5.94T scanned at 0B/s, 4.68T issued at 110M/s, 6.19T total
Click to expand...

Die 110 MiB/s bei dem Scrub (überprüfen aller Daten gegen die Checksummen) finde ich jetzt aber nicht sonderlich flott.


Alternativ schon mal mit einem der (noch vorhandenen?) älteren Kernel neu gestartet?
 
Das mit dem alten Kernel kann ich in der Nacht noch prüfen. Also auf allen anderen VM's auf dem genau gleichen Proxmox Server habe ich Durchsätze von 12 Gbyte/s schreiben und Lesen! Das geht eigentlich ganz Flott. Nur eben der eine jene Server nicht, wo immer wieder laggt und Proxmox selbst Probleme beim Öffnen der Konsole hat. Ich verstehe nicht ganz, warum dann nur 1 Server betroffen ist und nicht alle, wenn die Hardware nicht ausreichen würde. Ich habe mir schon überlegt, den Server einfach zu verschieben.
Auffällig ist auch, dass nach einem Neustart für einige Zeit die VM auch ganz flott ist und nach mehreren Minuten dann immer langsamer und langsamer wird, bis es Aussetzer gibt und Konsole nicht mehr erreichbar ist. Dann ist der Server besonders langsam.

Die Probleme haben wir erst seit wir Proxmox 7 nach langer Zeit mal neu gestartet haben. Ich vermute wir haben Proxmox 7 mal ganz am Anfang bei der Installation einmal installiert und dann nie mehr neugestartet, bis eben letzte Woche. Anschliessend haben wir jetzt noch Proxmox 8 aktualisiert.
 
ich kann nun das Problem weiter eingrenzen.
Ich wollte die betroffene VM auf ein baugleiches System weg schieben. Hat mit 200 Mbyte/s angefangen, aber dann brach die Übertragung nach 30 Sekunden auf 1 Mbyte/s zusammen. Auch ZFS Scrub wurde immer langsamer, Proxmox Konsole ging praktisch gar nie und der Server war nur sporadisch kurz online.
Nach mehreren Versuchen habe ich festgestellt, dass die Konsole in Proxmox immer etwa in der Hälfte beim Starten des Kernels einen Ausfall hatte. Ich habe dann den Server nur bis zu Grub gestartet und dann das System verschoben. Siehe da, ich konnte mit rund 1 Gbyte/s die Daten verschieben, beim Scrub vom ZFS gingen die Durchsätze hoch und die Konsole lief durchgängig weiter. Ich tippe jetzt einfach mal, dass es ein Softwareproblem ist. Der IO Delay ging jetzt auch nie über 0.3, wo ich vorher 2 oder 3 hatte.
Das einzige Problem das ich jetzt noch habe ist, dass das gleiche Phänomen auftritt, wenn ich einer der verbliebenen VM backupen will. Ich werde wohl mal versuchen das BIOS zu aktualisieren, einen älteren Kernel booten und sonst mal das System neu installieren.
 
Last edited:
chrigiboy said:
Ich wollte die betroffene VM auf ein baugleiches System weg schieben. Hat mit 200 Mbyte/s angefangen, aber dann brach die Übertragung nach 30 Sekunden auf 1 Mbyte/s zusammen. Auch ZFS Scrub wurde immer langsamer, Proxmox Konsole ging praktisch gar nie und der Server war nur sporadisch kurz online.
Nach mehreren Versuchen habe ich festgestellt, dass die Konsole in Proxmox immer etwa in der Hälfte beim Starten des Kernels einen Ausfall hatte. Ich habe dann den Server nur bis zu Grub gestartet und dann das System verschoben. Siehe da, ich konnte mit rund 1 Gbyte/s die Daten verschieben, beim Scrub vom ZFS gingen die Durchsätze hoch und die Konsole lief durchgängig weiter. Ich tippe jetzt einfach mal, dass es ein Softwareproblem ist. Der IO Delay ging jetzt auch nie über 0.3, wo ich vorher 2 oder 3 hatte.
Click to expand...
Verstehe ich das richtig? Du hast das OS auf eine andere Disk geschoben und dann fluppte alles deutlich besser?

Schau auch, ob es für die SSDs nicht auch ein Firmware Update gibt. Das klingt alles nämlich so, als ob OS, VMs, Migration und Scrub dazu, für die SSDs zu viel ist und diese nicht mehr hinterherkommen würden. Alles ein bisschen seltsam.
 
aaron said:
Verstehe ich das richtig? Du hast das OS auf eine andere Disk geschoben und dann fluppte alles deutlich besser?

Schau auch, ob es für die SSDs nicht auch ein Firmware Update gibt. Das klingt alles nämlich so, als ob OS, VMs, Migration und Scrub dazu, für die SSDs zu viel ist und diese nicht mehr hinterherkommen würden. Alles ein bisschen seltsam.
Click to expand...
Oder eine Disk stirbt langsam. Auch mal SMART Werte anschauen.
 
You must log in or register to reply here.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom