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

Auch wenn das neue Jahr immer noch den gleichen Fehler im Proxmox-Cluster hat, habe ich mal weiter gesucht.

Zum Test habe ich auf einem Proxmox-Server alle CT/VM aus dem HA genommen. Dann das lokale und das Proxmox-Backup gleichzeitig gestartet. Ergebniss: der I/O Wait geht erwartungsgemäß hoch, am Ende jedoch wieder den Normalwert zurück.

Also den HA-Modus abschalten? Dann brauche ich auch kein Proxmox mehr :(
 
Mit dem folgenden Kommando lässt sich ein Backtrace (dmesg) auslösen. Bitte mal beim Backup und dann wenn der Daemon im D State ist auslösen.
Code: 
echo 1 > /proc/sys/kernel/sysrq
echo l > /proc/sysrq-trigger
https://www.kernel.org/doc/html/v4.13/admin-guide/sysrq.html

Mittlerweile gibt es auch neuere Kernel im Repository die ein paar Fixes fürs Netzwerk besitzen.
 
Last edited:
pssss liegt das am Kernel oder habt ihr doch ein bug und findet ihn nicht.

Gruß

Markus
 
Hello. Yes, I know. But now I think my problem is not related to Ceph at all (all VM's and their IO are fine - no issues). It's just the host that's affected.

I think it's related to the cluster method Proxmox uses for HA (and pmxcfs). This is the same thing you are using, but you are not using Ceph storage. I also do not have any errors for file system/network or disk access.
 
Die Antwort trollt den bug ersteller schon ein wenig. Erst passiert nichts generell passiert im tracker nicht viel oder ich über seh es und dann so eine Antwort. Service habt ihr drauf.
 
wir habe nun einen ähnlichen oder diesen hänger in unserem testlab reproduzieren können und analysieren die genau ursache. um sicherzustellen dass es sich um dasselbe problem handelt, wären komplette logs von allen cluster nodes, insbesondere im zeitraum von 10 minuten vor der ersten "hung task" meldung bis inkl. der meldung hilfreich.

falls es sich nicht um produktivcluster handelt, sondern ein testsystem OHNE sensitive daten, wäre außerdem folgendes von vorteil:
- sammeln und aufheben eines coredumps vom pmxcfs (s.u.) auf dem node mit dem hung task.
- sammeln und posten eines backtraces vom pmxcfs (s.u.) auf dem node mit dem hung task.
- aufdrehen der debug option im pmxcfs ("-d") auf allen nodes vor dem starten des test - das produziert allerdings wesentlich längere logfiles ;)
- posten der kompletten komprimierten logfiles alle cluster nodes

generieren eines backtraces des laufenden pmxcfs:
Code: 
apt install pve-cluster-dbgsym fuse-dbg
gdb -batch -p $(pidof pmxcfs) -ex "thread apply all bt full"

generieren eines coredumps des laufenden pmxcfs:
Code: 
gdb -batch -p $(pidof pmxcfs) -ex generate-core-file

aufgrund der sensibilität des coredumps (enthält den gesamten memory des pmxcfs!) bitte auf keinen fall hier posten - falls aufgrund des backtraces / der logs konkret bedarf an einem bestimmten coredump besteht melden wir uns.
 
Hi,

Soweit ich weiß ist das ein produktiv Cluster, daraus Logs zuschicken ist unschön Daher wie kann man euch noch unterstützen damit es geht?

Der Lösungsansatz den wir gerade verfolgen, ist das alles ohne zfs aufzubauen. Und es funktioniert sogar in alt bekannter Zuverlässigkeit. Bei mir zumindestens.
 
Markus Thormann said:
Hi,

Soweit ich weiß ist das ein produktiv Cluster, daraus Logs zuschicken ist unschön Daher wie kann man euch noch unterstützen damit es geht?

Der Lösungsansatz den wir gerade verfolgen, ist das alles ohne zfs aufzubauen. Und es funktioniert sogar in alt bekannter Zuverlässigkeit. Bei mir zumindestens.
Click to expand...

wie oben bereits erwähnt, für produktivcluster:

wären komplette logs von allen cluster nodes, insbesondere im zeitraum von 10 minuten vor der ersten "hung task" meldung bis inkl. der meldung hilfreich.
Click to expand...

(lässt sich bei bedarf ja zensieren)
 
jms1000 said:
Man sollte sich vielleicht mal die Mühe machen den Beitrag von Anfang an zu lesen - ich habe kein HA mehr aktiv, da ich ein System brauche das funktioniert. Demnach habe ich keine Logs und kann ich auch nichts mehr testen.
Click to expand...

wie gesagt - testen und coredumps sind sowieso nur von testsystemen erwünscht.

wenn vom produktsystem die logs vom zeitpunkt der probleme nicht mehr vorhanden sind kann man natürlich nichts machen... niemand verlangt hier ein absichtliches provozieren von hängern auf produktivsystemen um logs zu bekommen? wir können einen hänger mit ähnlicher/identer symptomatik reproduzieren und arbeiten an einer lösung - die logs / debugging output würde uns beim abgleich helfen, um sicherzugehen dass es sich um dasselbe problem handelt.
 
Ich habe auf zum Test auf einem Prx-Server wieder alle Systeme in den HA-Modus verstetzt, Ergebnis ist bekannt I/O bleibt nach dem morgendlichen Backup wieder auf 15 stehen ...

Backup prx1 start 00:15 / ende 03:00
Backup prx2 start 00:15 / ende 02:29
Backup prx3 start 00:15 / ende 01:25
Backup prx4 start 00:15 / ende 04:43

Und ja, alle System sind auf dem aktuellen Stand des Repro.

Vielleicht hilft das Logfile ja.

(Falls jemand nicht scrollen möchte: Alle LXC/VM liegen auf einem Raid / lokal auf dem prx-systemengibt es nur ein ZFS mit dem Betriebssystem / Raindanbindung 10G, genutzt werden maximal 1,5G)
 

Attachments

  • prx.log
    76.1 KB · Views: 2
jms1000 said:
Ich habe auf zum Test auf einem Prx-Server wieder alle Systeme in den HA-Modus verstetzt, Ergebnis ist bekannt I/O bleibt nach dem morgendlichen Backup wieder auf 15 stehen ...

Backup prx1 start 00:15 / ende 03:00
Backup prx2 start 00:15 / ende 02:29
Backup prx3 start 00:15 / ende 01:25
Backup prx4 start 00:15 / ende 04:43

Und ja, alle System sind auf dem aktuellen Stand des Repro.

Vielleicht hilft das Logfile ja.

(Falls jemand nicht scrollen möchte: Alle LXC/VM liegen auf einem Raid / lokal auf dem prx-systemengibt es nur ein ZFS mit dem Betriebssystem / Raindanbindung 10G, genutzt werden maximal 1,5G)
Click to expand...

der trace vom hängenden task sieht auf jeden fall anders aus, auch wenn das log file ein bisschen durcheinander scheint (der hung task trace ist nur einmal vollständig gelogged?). kernel ist auf jeden fall hinten nach (-5-pve, aktuell ist -6-pve).

vielleicht lässt sich mit sys-rq ein kernel trace von allen prozessen machen (s.u.)? und von einem hängenden task und dem pmxcfs wäre ein backtrace mit gdb ebenfalls interessant (sh. vorheriges post), am besten zeitnah zu den kernel traces

Code: 
echo 1 | /proc/sys/kernel/sysrq
echo t | /proc/sysrq-trigger
echo 0 | /proc/sys/kernel/sysrq

und dann den relevanten (langen!) teil aus /var/log/kern.log kopieren und alles zusammen mit "pveversion -v" output posten. danke!
 
Traces kann ich leider keine mehr anlegen, da das system gebootet wurde, es muss ja laufen.

Mar 12 00:24:06 prx1 kernel: [30087.644109] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 12 00:24:06 prx1 kernel: [30087.644138] io_schedule+0x16/0x40
Mar 12 00:24:06 prx1 kernel: [30087.644159] shmem_unused_huge_scan+0x23/0x30
Mar 12 00:24:06 prx1 kernel: [30087.644167] do_try_to_free_pages+0xef/0x360
Mar 12 00:24:06 prx1 kernel: [30087.644175] alloc_pages_current+0x6a/0xe0
Mar 12 00:24:06 prx1 kernel: [30087.644182] __handle_mm_fault+0x992/0x1040
Mar 12 00:24:06 prx1 kernel: [30087.644189] do_page_fault+0x22/0x30
Mar 12 00:24:06 prx1 kernel: [30087.644194] RAX: 0000000000000000 RBX: 00005579f3a415a0 RCX: 0000000000000000
Mar 12 00:26:07 prx1 kernel: [30208.474500] shrink_node+0x108/0x310
Mar 12 00:26:07 prx1 kernel: [30208.474509] pte_alloc_one+0x17/0x40
Mar 12 00:26:07 prx1 kernel: [30208.474523] RAX: 0000000000000000 RBX: 00005579f3a415a0 RCX: 0000000000000000
Mar 12 00:28:08 prx1 kernel: [30329.308980] shmem_unused_huge_scan+0x23/0x30
Mar 12 00:28:08 prx1 kernel: [30329.308991] __alloc_pages_slowpath+0x411/0xe80
Mar 12 00:28:08 prx1 kernel: [30329.309001] alloc_set_pte+0x4f6/0x550
Mar 12 00:28:08 prx1 kernel: [30329.309010] ? filp_close+0x56/0x80
Mar 12 00:28:08 prx1 kernel: [30329.309017] RAX: 0000000000000000 RBX: 00005579f3a415a0 RCX: 0000000000000000
Mar 12 00:30:09 prx1 kernel: [30450.135364] INFO: task pve-ha-lrm:20739 blocked for more than 120 seconds.
Mar 12 00:30:09 prx1 kernel: [30450.135384] Tainted: P O 4.13.13-5-pve #1
Mar 12 00:30:09 prx1 kernel: [30450.135396] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 12 00:30:09 prx1 kernel: [30450.135411] pve-ha-lrm D 0 20739 4022 0x00000000
Mar 12 00:30:09 prx1 kernel: [30450.135413] Call Trace:
Mar 12 00:30:09 prx1 kernel: [30450.135417] __schedule+0x3cc/0x850
Mar 12 00:30:09 prx1 kernel: [30450.135418] schedule+0x36/0x80
Mar 12 00:30:09 prx1 kernel: [30450.135422] __lock_page+0xff/0x140
Mar 12 00:30:09 prx1 kernel: [30450.135423] ? page_cache_tree_insert+0xc0/0xc0
Mar 12 00:30:09 prx1 kernel: [30450.135426] shmem_unused_huge_shrink+0x20f/0x350
Mar 12 00:30:09 prx1 kernel: [30450.135428] super_cache_scan+0x190/0x1a0
Mar 12 00:30:09 prx1 kernel: [30450.135430] shrink_slab+0x29/0x30
Mar 12 00:30:09 prx1 kernel: [30450.135433] try_to_free_pages+0xf2/0x1b0
Mar 12 00:30:09 prx1 kernel: [30450.135440] pte_alloc_one+0x17/0x40
Mar 12 00:30:09 prx1 kernel: [30450.135444] ? do_mmap+0x445/0x510
Mar 12 00:30:09 prx1 kernel: [30450.135450] page_fault+0x4c/0x60
Mar 12 00:30:09 prx1 kernel: [30450.135454] R10: 0000000000000011 R11: 0000000000000246 R12: 000000000000001c
Mar 12 00:32:10 prx1 kernel: [30570.969869] Tainted: P O 4.13.13-5-pve #1
Mar 12 00:32:10 prx1 kernel: [30570.969901] __schedule+0x3cc/0x850
Mar 12 00:32:10 prx1 kernel: [30570.969908] ? page_cache_tree_insert+0xc0/0xc0
Mar 12 00:32:10 prx1 kernel: [30570.969914] shrink_slab.part.48+0x1f5/0x410
Mar 12 00:32:10 prx1 kernel: [30570.969919] __alloc_pages_slowpath+0x411/0xe80
Mar 12 00:32:10 prx1 kernel: [30570.969925] __pte_alloc+0x1e/0x110
Mar 12 00:32:10 prx1 kernel: [30570.969930] handle_mm_fault+0xce/0x1c0
Mar 12 00:32:10 prx1 kernel: [30570.969935] page_fault+0x4c/0x60
Mar 12 00:32:10 prx1 kernel: [30570.969938] RBP: 0000000000000002 R08: 00007ffe565bfb80 R09: 00000000ffffffff
Mar 12 00:34:11 prx1 kernel: [30691.796499] __lock_page+0xff/0x140
Mar 12 00:34:11 prx1 kernel: [30691.796505] super_cache_scan+0x190/0x1a0
Mar 12 00:34:11 prx1 kernel: [30691.796510] do_try_to_free_pages+0xef/0x360
Mar 12 00:34:11 prx1 kernel: [30691.796516] alloc_pages_current+0x6a/0xe0
Mar 12 00:34:11 prx1 kernel: [30691.796521] __handle_mm_fault+0x992/0x1040
Mar 12 00:34:11 prx1 kernel: [30691.796526] do_page_fault+0x22/0x30
Mar 12 00:34:11 prx1 kernel: [30691.796531] RAX: 0000000000000000 RBX: 00005579f3a415a0 RCX: 0000000000000000
Mar 12 00:36:11 prx1 kernel: [30812.626783] io_schedule+0x16/0x40
Mar 12 00:36:11 prx1 kernel: [30812.626792] super_cache_scan+0x190/0x1a0
Mar 12 00:36:11 prx1 kernel: [30812.626797] try_to_free_pages+0xf2/0x1b0
Mar 12 00:36:11 prx1 kernel: [30812.626804] pte_alloc_one+0x17/0x40
Mar 12 00:36:11 prx1 kernel: [30812.626810] handle_mm_fault+0xce/0x1c0
Mar 12 00:36:11 prx1 kernel: [30812.626815] page_fault+0x4c/0x60
Mar 12 00:36:11 prx1 kernel: [30812.626819] R10: 0000000000000011 R11: 0000000000000246 R12: 000000000000001c
Mar 12 00:38:12 prx1 kernel: [30933.457172] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 12 00:38:12 prx1 kernel: [30933.457198] __lock_page+0xff/0x140
Mar 12 00:38:12 prx1 kernel: [30933.457206] super_cache_scan+0x190/0x1a0
Mar 12 00:38:12 prx1 kernel: [30933.457214] __alloc_pages_slowpath+0x411/0xe80
Mar 12 00:38:12 prx1 kernel: [30933.457222] __pte_alloc+0x1e/0x110
Mar 12 00:38:12 prx1 kernel: [30933.457227] handle_mm_fault+0xce/0x1c0
Mar 12 00:38:12 prx1 kernel: [30933.457234] RIP: 0033:0x7fc4e8a99a57
Mar 12 00:38:12 prx1 kernel: [30933.457236] R10: 0000000000000011 R11: 0000000000000246 R12: 000000000000001c
Mar 12 00:40:13 prx1 kernel: [31054.287513] Tainted: P O 4.13.13-5-pve #1
Mar 12 00:40:13 prx1 kernel: [31054.287549] schedule+0x36/0x80
Mar 12 00:40:13 prx1 kernel: [31054.287558] shmem_unused_huge_scan+0x23/0x30
Mar 12 00:40:13 prx1 kernel: [31054.287564] try_to_free_pages+0xf2/0x1b0
Mar 12 00:40:13 prx1 kernel: [31054.287573] __pte_alloc+0x1e/0x110
Mar 12 00:40:13 prx1 kernel: [31054.287579] __do_page_fault+0x256/0x4f0
Mar 12 00:40:13 prx1 kernel: [31054.287584] RSP: 002b:00007ffe565bf9e0 EFLAGS: 00010246
Mar 12 00:42:14 prx1 kernel: [31175.117997] schedule+0x36/0x80
Mar 12 00:42:14 prx1 kernel: [31175.118002] pagecache_get_page+0x196/0x210
Mar 12 00:42:14 prx1 kernel: [31175.118007] shrink_slab.part.48+0x1f5/0x410
Mar 12 00:42:14 prx1 kernel: [31175.118011] try_to_free_pages+0xf2/0x1b0
Mar 12 00:42:14 prx1 kernel: [31175.118017] alloc_pages_current+0x6a/0xe0
Mar 12 00:42:14 prx1 kernel: [31175.118021] finish_fault+0x3e/0x70
Mar 12 00:42:14 prx1 kernel: [31175.118025] __do_page_fault+0x256/0x4f0
Mar 12 00:42:14 prx1 kernel: [31175.118029] page_fault+0x4c/0x60
Mar 12 00:42:14 prx1 kernel: [31175.118031] RDX: 0000000000000000 RSI: 00007fc4df750000 RDI: 00007fc4eef2a000
Mar 12 00:42:14 prx1 kernel: [31175.118032] R13: 0000000000000010 R14: 0000000000000000 R15: 0000000000000010

pve-manager: 5.1-43 (running version: 5.1-43/bdb08029)
pve-kernel-4.13.13-4-pve: 4.13.13-35
pve-kernel-4.13.13-2-pve: 4.13.13-33
pve-kernel-4.10.17-4-pve: 4.10.17-24
pve-kernel-4.10.17-2-pve: 4.10.17-20
pve-kernel-4.13.8-3-pve: 4.13.8-30
pve-kernel-4.13.13-5-pve: 4.13.13-38
pve-kernel-4.13.13-1-pve: 4.13.13-31
pve-kernel-4.10.17-3-pve: 4.10.17-23
libpve-http-server-perl: 2.0-8
lvm2: 2.02.168-pve6
corosync: 2.4.2-pve3
libqb0: 1.0.1-1
pve-cluster: 5.0-19
qemu-server: 5.0-20
pve-firmware: 2.0-3
libpve-common-perl: 5.0-25
libpve-guest-common-perl: 2.0-14
libpve-access-control: 5.0-7
libpve-storage-perl: 5.0-17
pve-libspice-server1: 0.12.8-3
vncterm: 1.5-3
pve-docs: 5.1-16
pve-qemu-kvm: 2.9.1-6
pve-container: 2.0-18
pve-firewall: 3.0-5
pve-ha-manager: 2.0-4
ksm-control-daemon: 1.2-2
glusterfs-client: 3.8.8-1
lxc-pve: 2.1.1-2
lxcfs: 2.0.8-1
criu: 2.11.1-1~bpo90
novnc-pve: 0.6-4
smartmontools: 6.5+svn4324-1
zfsutils-linux: 0.7.4-pve2~bpo9
 
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
Back