Regelmäßige IO Probleme

ich hatte das auch mal: https://forum.netcup.de/sonsti…?postID=190894#post190894
der betroffene server wurde auch verschoben. damit wurde es deutlich besser.

noch mehr besserung brachte es im servercontrolpanel (unter medien) von SCSI auf virtio zu wechseln

Also wenn mehrfaches verschieben nicht geholfen hat würde ich das Problem eventuell mal bei dir suchen. Welcher Prozess landet denn im IO Wait? Hast du potentiell IO intensive Prozesse drauf? Ist ausgeschlossen dass sich Cronjobs überholen und mehrfach laufen? Wie lange dauert es denn nach einem Neustart bis das Problem wieder auftritt?

Bei mir äußert sich das immer in der folgenden Grafik. Disk Queue Length des Root Device steigt und dann folgt die Kettenreaktion:
pasted-from-clipboard.png

Die Node ist Teil eines Clusterverbundes und alle schreiben die gleichen "persistenten" Daten. In der Vergangenheit war speziell nach den Sonderangeboten mehr Spikes zu erkennen. Daher habe ich bisher 3mal eine Node verschieben lassen und danach war auch auf absehbare Zeit erstmal wieder Ruhe.

Habe das auch seit heute Morgen. Führt auch schon zu CPU stalls

watchdog: BUG: soft lockup - CPU#7 stuck for 58s! [kworker/7:2:27872]

[45791055.278039] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:

Message from syslogd@xxx at May  4 20:52:07 ...
 kernel:[45787478.310296] Uhhuh. NMI received for unknown reason 30 on CPU 1.

Message from syslogd@xxx at May  4 20:52:07 ...
 kernel:[45787478.310296] Do you have a strange power saving mode enabled?

Message from syslogd@xxx at May  4 20:52:07 ...
 kernel:[45787478.310297] Dazed and confused, but trying to continue

Ich dachte dass ich der einzige bin. Hatte das Problem auch bisher einmal, dann Serverwechsel, aber jetzt ist das Problem wieder zurück. Der Server läuft unter Windows, da zeigt sich das Problem so, dass die Datenträgerlast auf 100% hängt, dabei aber nur 3-8 Mbytes/s bewegt werden.

Zusatzinfos: Der Festplattendurchsatz auf der betroffenen Maschine is zu den betroffenen Zeiten (Problem ist mal ein paar Minuten da und dann wieder weg) unterirdisch. Problem tritt mit SCSI und virtio auf.

root@xxx:~# hdparm -tT /dev/vda
/dev/vda:
 Timing cached reads:   14274 MB in  2.00 seconds = 7142.40 MB/sec
 Timing buffered disk reads: 134 MB in 21.32 seconds =   6.28 MB/sec


Als Referenz, ein anderer Server bei Netcup (der unter viel höherer I/O-Last steht):
root@xxx:# hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   12874 MB in  2.00 seconds = 6444.20 MB/sec
 Timing buffered disk reads: 3556 MB in  3.00 seconds = 1184.37 MB/sec

Zweite Referenz, eine VM beim roten H:
root@xxx:~# hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   34862 MB in  2.00 seconds = 17473.25 MB/sec
 Timing buffered disk reads: 6206 MB in  3.00 seconds = 2068.59 MB/sec

Habe zum Beitrag oben weitere Screenshots hinzugefügt.

Der Netcup Support möchte, dass ich das im Rettungssystem ebenfalls teste - ist natürlich immer etwas schwierig, ein zeitweise auftretendes Problem im Rettungssysem nachzustellen, während ein kurzer Blick auf den Host dieses Problem direkt sichtbar werden ließe...

Zitat von peterbo

Der Netcup Support möchte, dass ich das im Rettungssystem ebenfalls teste -

Das wollten sie bei mir auch. Habe dann unter Windows einen 0Mbytes/s Durchsatz bei 100% Aktivität Screenshot geschickt. Hat wohl gereicht.

Das Rettungssystem bestätigt aber das Hardwareproblem:

hdparm misst einen Lesedurchsatz von satten 950KB/s:

Der Notfallsupport hat den Hardwaredefekt bestätigt und die VM verschoben. Erste Idee war, dass der RAID-Verbund oder RAID-Controller den Geist aufgegeben haben. Die Lösung war über den Notfallsupport gut, schnell und zielführend, aber ein Beigeschmack, warum ein solches Problem im Monitoring nicht auffällt / eskaliert wird, bleibt.

Ergänzung für das volle Bild: Meine Anfrage beim "normalen" Support vom Donnerstagabend, blieb bis zum Anruf beim Notfallsupport am Samstagmorgen unbeantwortet. Schade, dass sich das niemand auch nur kurz angeschaut hat.

Zitat von peterbo

Der Notfallsupport hat den Hardwaredefekt bestätigt und die VM verschoben. Erste Idee war, dass der RAID-Verbund oder RAID-Controller den Geist aufgegeben haben. Die Lösung war über den Notfallsupport gut, schnell und zielführend, aber ein Beigeschmack, warum ein solches Problem im Monitoring nicht auffällt / eskaliert wird, bleibt.

Dann fragt man sich, warum steht so eine Störung dann nicht mit auf der Störungsseite? Denn es betrifft ja mehrere Kunden.

Zitat von andreas.

Dann fragt man sich, warum steht so eine Störung dann nicht mit auf der Störungsseite? Denn es betrifft ja mehrere Kunden.

Weil die wahrscheinlich manuell aktualisiert werden muss. Ist offensichtlich nicht direkt mit dem Monitoring gekoppelt

Zitat von andreas.

Dann fragt man sich, warum steht so eine Störung dann nicht mit auf der Störungsseite? Denn es betrifft ja mehrere Kunden.

Ich kenne persönlich keinen Anbieter, der das in der Form kommuniziert / automatisiert hat. Stelle mir auch die Frage wie man solche Dinge auf dem Wirtssystem sauber erkennen will, wenn einfach nur die Datenraten nicht in Ordnung sind, das Raid aber schon.

Ist halt schon bedenklich, dass da anscheinend mehrere Hosts und auch immer wieder betroffen sind.

Bei mit heute auch: war ein Hardwaredefekt, ist behoben. Performance wieder auf üblichem Niveau. Im Januar hatte ich das aber auch schon...

domett ich glaube, ich fühle mit dir. Wir fahren gute 100 RS bei netcup, der große Anteil der Server hat eine bestimmte Aufgabe ohne besondere Technologien wie Virtualisierung oder Containern. Teilweise betreiben wir Seiten mit ~100k Visits pro Tag, ihr könnt euch sicherlich vorstellen, wie ein solcher iowait Spike bei diesem verhalten aussieht und leider könnte ich gerade keinen einzigen Server nennen, der dieses Problem nicht hat. Bspw. dieser hier, auf dem nichts läuft außer ein idle nginx als fallback:

idle.PNG

Ist schon was her, dass ich das letzte mal darüber mit dem Support geschrieben habe, mit der Arbeit, die es mir macht, ins Rettungssystem zu booten und dann darauf zu hoffen, dass ich einen Spike irgendwie für den Support nachgewiesen bekomme, könnte ich eine Studi-Stelle ausfüllen.

Unser k8s EventLog sieht auch ziemlich farbenfroh aus.. immerhin sind die Ausfälle hier nicht so schmerzhaft weil alles im HA und mit x replicas läuft.

Danke für diese Infos hier. Ich habe seit Monaten genau dieses Problem: mein Server steht jeden Tag mehrmals für 30-60 Sekunden nahezu still, obwohl sich da nur ein paar Container langweilen. Ein uptime zeigt in diesen Momenten regelmäßig ein Load von mindestens Zweistellig an.

Habe schon an mir selbst gezweifelt.

Schreib ein Ticket. Bei mir wars, wie gesagt, ein HW Defekt auf dem Host. Bei mir ists Windows, aber ich würde vermuten dass Linux hier bei stoppender SSD Performance ein sehr hohes I/O Wait in top anzeigen würde.