Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Dr. Bakterius]

@a200 Die aktuelle Auslastung ist mit 11% normal. Steigt die dann mit der Zeit an?

[a200]

@dr-bakterius @Thomas-Braun - Das ist, was ich mit entspannt meine. Durchschnittlich bei 10-20% CPU. Ich werde ihn jetzt 2 CPU mit je 2 Kernen spendieren. Mal sehen ob es besser wird. Allerdings ist die Auslastung weder bei iobroker noch bei proxmox so hoch gewesen. Auffallend ist, dass die Netzwerkverbindung weg ist. Über den Hardware-Button lässt sich der Server locker ausschalten...

@MartinP - Auf Node 22.x bin ich erst vor ein paar Tagen umgestiegen. Die Probleme gab es schon früher.

[Wildbill]

@a200 Nachdem Dein Log oben mit backitup-Meldungen beginnt, würde ich mal da schauen. Kann es sein, dass Dir da bei einem laufenden Backup einfach der Speicher in der VM ausgeht (Backitup braucht da schnell ziemlich viel) und dann nach und nach vom System die einzelnen Prozesse abgeschossen werden? darauf würde auch hinweisen, dass danach die Adapter wieder anlaufen und die Disk-IO in die Höhe schießt.

Gruss, Jürgen

[a200]

@wildbill - habe auch schon daran gedacht. Die Messungen von Proxmox sind zu selten, dass ein sehr schneller Anstieg + Exitus dort nicht sichtbar sind. Allerdings sollte nur die VM davon betroffen sein nicht die komplette Proxmox Instanz. Wobei ist es nicht gesagt, dass alle Ressourcen von Proxmox betroffen sind, wenn nur das betroffen ist... Fragen über Fragen. Ich muss schauen ob ich das Netzwerk device von Proxmox extra überwachen kann. Ist eine komplexe Geschichte.

[Wildbill]

@a200 Dass Proxmox als Host ausgebremst wird, sehe ich da als Folge. Wenn die iobroker-VM (warum jetzt auch immer) plötzlich viel Disk-IO erzeugt, dann steigt eben die Gesamt-Last. Und oben sieht man ja bereits ein IO-Delay beim Host, also liest/schreibt da in iobroker irgendwas über Gebühr. Oder irgendein Adapter/Gerät hantiert da mit so vielen Daten, dass es eben den Host ausbremst.

Gruss, Jürgen

EDIT: Passiert das immer zu festen Zeiten, also beispielsweise wenn Backitup aktiv wird?

[a200]

@wildbill - Nein, es passiert sehr unregelmäßig. die letzten beide Male, als ich in IoBroker war. Aber es passierte auch so zwischendurch. Allerdings reden wir von ca. 2 x im Monat.

[crunchip]

@a200 zu einen würde ich mal das syslog von Proxmox kontrollieren. Dann auch mal die Temperaturen ansehen und zum Thema CPU, ja mehr Power geben, man muss nicht sparen, Proxmox regelt das selbst

[a200]

@crunchip In der Nacht ist es wieder passiert. An der CPU liegt es nicht. Der IoBroker lief laut logfils ununterbrochen weiter. Also scheint es ein Problem mit dem Netzwerkdevice zu geben. Ich habe jetzt den Proxmoxadapter in IoBroker eingeschaltet um zu sehen ob die interne Kommunikation (über virtuelle devices) stabil ist. Jetzt werde ich auch auf der Proxmoxseite gucken. Ich werde ein Skript aufsetzen, der bei fehlerhaften ping ein restart des networking.service ausführt.
Hat einer eine Idee wo in Proxmox ich nach einem Reboot Informationen zu dem Problem/Netzwerkausfall/was auch immer finden kann?

[MartinP]

@a200 Ist der Proxmox-PC per LAN-Kabel oder per WLAN mit dem Heimnetz verbunden?

WLAN wird für Proxmox nicht empfohlen.

[a200]

@martinp LAN natürlich

[crunchip]

@a200 sagte in IoBroker in VM legt kompletten Proxmox-Server lahm.:

Hat einer eine Idee wo in Proxmox ich nach einem Reboot Informationen zu dem Problem/Netzwerkausfall/was auch immer finden kann?

@crunchip sagte in IoBroker in VM legt kompletten Proxmox-Server lahm.:

das syslog von Proxmox kontrollieren

[a200]

@crunchip scheint ein bekanntes Problem zu sein:

2025-08-28T14:59:38.912818+02:00 pve kernel: [264641.580371] e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
2025-08-28T14:59:38.912833+02:00 pve kernel: [264641.580371]   TDH                  <7f>
2025-08-28T14:59:38.912835+02:00 pve kernel: [264641.580371]   TDT                  <b0>
2025-08-28T14:59:38.912836+02:00 pve kernel: [264641.580371]   next_to_use          <b0>
2025-08-28T14:59:38.912837+02:00 pve kernel: [264641.580371]   next_to_clean        <7e>
2025-08-28T14:59:38.912839+02:00 pve kernel: [264641.580371] buffer_info[next_to_clean]:
2025-08-28T14:59:38.912840+02:00 pve kernel: [264641.580371]   time_stamp           <10fc1780f>
2025-08-28T14:59:38.912842+02:00 pve kernel: [264641.580371]   next_to_watch        <7f>
2025-08-28T14:59:38.912843+02:00 pve kernel: [264641.580371]   jiffies              <10fc19c80>
2025-08-28T14:59:38.912845+02:00 pve kernel: [264641.580371]   next_to_watch.status <0>
2025-08-28T14:59:38.912858+02:00 pve kernel: [264641.580371] MAC Status             <40080083>
2025-08-28T14:59:38.912860+02:00 pve kernel: [264641.580371] PHY Status             <796d>
2025-08-28T14:59:38.912861+02:00 pve kernel: [264641.580371] PHY 1000BASE-T Status  <3800>
2025-08-28T14:59:38.912862+02:00 pve kernel: [264641.580371] PHY Extended Status    <3000>
2025-08-28T14:59:38.912863+02:00 pve kernel: [264641.580371] PCI Status             <10>

root@pve:~/Marek/Proxmox-logfile# grep "Detected Hardware Unit Hang" a |wc -l
3721

Muss hier weiter gucken: https://forum.proxmox.com/threads/e1000-driver-hang.58284/

Danke.

[crunchip]

@a200 hast du in deiner VM Netzwerk E1000 eingestellt, anstatt VirtIO (paravirtualized)?

[a200]

@crunchip nein. Aber es scheint weniger mit der VM, als mehr mit Proxmox zu tun haben. e1000 ist das physikalische Device bei dem NUC und das scheint ein Problem bei den neuen Kernels zu machen. Ich habe jetzt die empfohlene offloading Einstellung genommen. Mal sehen wie lange es hält.

Vielen Dank für deine Unterstützung.

ethtool -K eno1 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off

[crunchip]

@a200 virtio sollte keine Probleme bereiten und die Performance ist auch besser

[Kalle Blomquist]

@a200
Wenn bei dir wieder alles läuft und du ein bisschen Zeit hast, schau dir doch mal den Proxmox-Metrikserver an. Damit kann man Probleme schon ganz gut aufspüren.
Siehe:

[David G.]

@a200 sagte in IoBroker in VM legt kompletten Proxmox-Server lahm.:

@crunchip nein. Aber es scheint weniger mit der VM, als mehr mit Proxmox zu tun haben. e1000 ist das physikalische Device bei dem NUC und das scheint ein Problem bei den neuen Kernels zu machen. Ich habe jetzt die empfohlene offloading Einstellung genommen. Mal sehen wie lange es hält.

Vielen Dank für deine Unterstützung.

ethtool -K eno1 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off

Das kann es gut gewesen sein.
Ich hatte genau das selbe Problem.
Bei mir ist es nach oder bei großen Backups aufgetreten die der PBS über das Internet versendet hat.

Bei mir reicht ein

ethtool -K enp0s31f6 tso off gso off gro off

damit alles sauber läuft.
Hab es allerdings nach den letzten 2-3 reboots nicht mehr gemacht, ka ob sich das Problem mittlerweile gelöst hat....

[isi07]

Ist die Proxmox Installation aktuell? Ich erinner mich, dass ich das beschriebene Verhalten auch mal hatte mit einem NUC und einem e1000 Netzwerkadapter. Hin und wieder war der komplette Host nicht mehr erreichbar und konnte nur über den Knopf aus und wieder eingeschaltet werden. Ist aber bestimmt schon zwei Jahre her.
Bei mir lag es damals an Problemen mit dem Treiber im Kernel. Da musste ich dann für eine weile per dpks (oder so ähnlich) eine neuere Treiberversion hinzufügen. Seit einer Weile läuft bei mir aber alles wieder stabil mit dem aktuellen Kernel ohne Erweiterung.
Vielleicht mal im Proxmox forum suchen.
Viel Erfolg

[David G.]

@isi07

Ich hatte es auf jedem Fall bis vor ca 6 Monaten, System immer aktuell.

Ob es wirklich weg ist, oder nur nicht mehr auftritt weil die großen Backups durch sind weiß ich nicht.
Das Problem trat auch erst seit den großen Backups auf.

[MartinP]

Allgemein an das Forum - welche(n) physischen Netzwerk-Adapter man hat, kann man in der pve Shell folgendermaßen herausfinden:

root@pve:~# lshw -short |grep network
/0/100/1c.3/0          enp3s0     network     RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller