Läuft wirklich noch dieser kernel? Hier gabs viele Probleme, diesen Kernel auf keinen Fall verwenden.
pve-ha-lrm I/O Wait ...
- Thread starter jms1000
- Start date
-
- Tags
- backup pve-ha-lrm
Läuft wirklich noch dieser kernel? Hier gabs viele Probleme, diesen Kernel auf keinen Fall verwenden.
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.
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.
okay, das gibt auch nicht viel her..
die logs und pveversion sagen beide das 4.13.13-5-pve läuft
Gestern Update und heute nochmal das ganze. Kern.log und pveversion anbei.
Nachtrag: mal noch wunschgemäß ein atop dazu ...
Nachtrag: mal noch wunschgemäß ein atop dazu ...
Last edited:
swap ist auf /dev/zvol/rpool/swap, mit der default installtion. das zfs liegt auf einem raid10 mit nsata disks.
ich würde empfehlen die swap properties noch mal gegenzuchecken (sh. https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS#step-7-configure-swap) um die auswirkungen vom swappen möglichst gering zu halten, und den ARC stärker zu beschränken damit es weniger leicht zum swappen kommt.
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
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 ...
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!