pve-ha-lrm I/O Wait ...

...
pve-kernel-4.13.13-4-pve: 4.13.13-35
....

Läuft wirklich noch dieser kernel? Hier gabs viele Probleme, diesen Kernel auf keinen Fall verwenden.
 
Das Problem besteht ja schon seit xxx Kernelversionen vorher ... ich tausche aber mal und teste morgen früh nochmal.

bitte wenn irgendwie mögliche beim testen die traces (kernel & gdb) speichern - die hung tasks sagen leider nicht sehr viel außer dass es probleme beim memory management zu geben scheint..
 
Das proxmox-backup ist heute morgen durch gelaufen (I/O wieder unten), das lokale Backup (Backup-Files vom NFS auf eine normale SATA-Disk im Proxmox-Server auf der xfs läuft), bringt meinen Freund den pve-ha-lrm wieder in den Status "D".
Kernel-Trace (ist das so ok?) und pveversion anbei.
 

Attachments

  • pveversion.log.gz
    521 bytes · Views: 3
  • trace.log.gz
    25.3 KB · Views: 4
Das proxmox-backup ist heute morgen durch gelaufen (I/O wieder unten), das lokale Backup (Backup-Files vom NFS auf eine normale SATA-Disk im Proxmox-Server auf der xfs läuft), bringt meinen Freund den pve-ha-lrm wieder in den Status "D".
Kernel-Trace (ist das so ok?) und pveversion anbei.

läuft auf dem system atop oder ein anderes monitoring tool das memory last detailliert mitprotokolliert? der kernel trace gibt nicht viel her außer das die hängenden tasks alle in memory-related kernel bereichen hängen.. die pveversion sagt immer noch nicht aktueller kernel ;)

interessant wäre auch noch ein testlauf mit dem preview 4.15er kernel (meta-paket pve-kernel-4.15 in pve-no-subscription), falls das möglich ist.
 
Ist gibt maximal eine Zabbix Grafik (siehe Anhang)
okay, das gibt auch nicht viel her..

Etwas aktuelleres als Linux prx1 4.13.13-6-pve #1 SMP PVE 4.13.13-41 (Wed, 21 Feb 2018 10:07:54 +0100) x86_64 gibt es nicht via Update.

die logs und pveversion sagen beide das 4.13.13-5-pve läuft
 
atop shows you are out of memory and swapping, the instability is likely a result of this. where is your swap located?
 
sieht soweit passend aus. und limitiert ist auch (das funktioniert dann wohl mal gar nicht?):

cat /etc/modprobe.d/zfs.conf
options zfs zfs_arc_min=2147483648
options zfs zfs_arc_max=4294967296

lässt sich mit "arc_summary.py" feststellen.. aber eventuell frisst ja auch was anderes den RAM - atop von anfang an mitlaufen lassen sollte die ursache eingrenzen lassen..
 
Push - gibt es Neuigkeiten zum Thema? Ich habe leider nur begrenzte Möglichkeiten auf dem produktiven Cluster zu testen.

Gedanke: Vermutlich ist ja der Speicherbedarf des ZFS die Ursache (ohne ZFS treten bei einem Kollegen keinerlei Probleme auf), obwohl der in der zfs.conf limitiert ist... Warum aber das ZFS den Speicher "frisst" obwohl dort nur das Betriebssystem und kein Backup/LXC/VM liegt, verstehe ich nicht so ganz ...
 
ich habe gerade https://bugzilla.proxmox.com/show_bug.cgi?id=1633 aktualisiert, sieht nach nem kernel bug seit 4.5 aus, patches sind schon zum review auf pve-devel und hoffentlich bald in einem kernel update verfügbar.

kernel pakete sind auf pvetest (sh. bug) - bitte um feedback ob das problem mit den aktualisierten paketen (nach einem reboot) noch reproduzierbar ist!
 

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!