Wiederkehrender Server Komplettausfall durch hängende Festplatten-I/O — Ticket seit 2 Tagen ohne Reaktion

Hallo zusammen,

seit Sonntagvormittag habe ich mit meinem vServer ein wiederkehrendes, schwerwiegendes Problem: Der Server hängt sich unter Last komplett auf — Load-Average steigt auf über 30, die Festplatte reagiert dann über längere Zeit gar nicht mehr, sämtliche Dienste werden unerreichbar. Ein harter Reset über die Kontrollseite hilft jeweils nur für 5-15 Minuten, danach tritt der Hänger erneut auf. Das ist inzwischen mehrfach wiederholt aufgetreten.

Ich habe das systematisch eingegrenzt:

• Selbst bei komplett gestoppten eigenen Anwendungen, also ganz ohne eigene Serverlast, hängt ein einfacher Festplatten-Schreibtest weiterhin zuverlässig fest.
• Eine Dateisystem-Prüfung zeigt bereits reale Inkonsistenzen (Block-Bitmap-Differenzen, falsche Frei-Zähler, Checksum-Fehler), vermutlich durch die wiederholten erzwungenen Resets während blockierter Schreibvorgänge entstanden.

Das deutet stark auf ein Problem mit der Storage-Anbindung des zugrunde liegenden Host-Systems hin, nicht auf eine eigene Fehlkonfiguration.

Ich habe dazu bereits am Sonntagnachmittag ein Support-Ticket erstellt, bislang leider ohne jede Rückmeldung. Auch die Hotline ist aktuell nicht erreichbar. Da der Server für mich inzwischen seit Tagen nicht nutzbar ist und sich das Problem wiederholt, wollte ich hier im Forum nachfragen, ob jemand vom Team das aufnehmen und intern eskalieren kann.

----------------------------------------------

EDIT:

• Auch bei komplett gestoppten eigenen Anwendungen, also ohne nennenswerte Last im Gast, treten massive Probleme bei Schreibzugriffen auf.
• Einfache Schreibtests liefen teils nicht normal bzw. zeigten stark reduzierte Schreibleistung.
• Die Dateisystem-Prüfung hat bereits Inkonsistenzen festgestellt, darunter Block-Bitmap-Differenzen, fehlerhafte Frei-Zähler und Checksum-Fehler. Diese Schäden sind aus meiner Sicht plausibel als Folge wiederholter erzwungener Resets während blockierter oder stark verzögerter Schreibvorgänge.
• Im Rettungssystem habe ich fsck -f auf den betroffenen Partitionen ausgeführt. Danach ließ sich das Dateisystem zwar reparieren, die eigentliche Auffälligkeit blieb jedoch bestehen.
• Nach Neustart sowie auch nach der Reparatur im Rettungssystem läuft ein direkter Schreibtest zwar ohne kompletten Timeout durch, erreicht aber weiterhin nur etwa 26 MB/s.
• Das liegt massiv unter den zuvor auf demselben System beobachteten Vergleichswerten von etwa 381 MB/s Schreiben und 564 MB/s Lesen.
• Es liegt damit aktuell nicht zwingend ein kompletter Totalausfall vor, aber weiterhin eine dauerhaft massiv reduzierte Schreibleistung.
• Da das Verhalten auch ohne eigene Last auftritt und nach Dateisystem-Reparatur unverändert bestehen bleibt, spricht das aus meiner Sicht eher für ein sporadisches bzw. anhaltendes Storage-/I/O-Problem auf Host-Ebene als für eine Fehlkonfiguration innerhalb der VM.

Vielen Dank

Hallo andreas.danke für deine Antwort.

Hier das Ergebnis, komplett im Rettungssystem durchgeführt. Also völlig unabhängig von meinem eigenen System, keinerlei eigene Software oder Dienste liefen dabei:

13:18:40 → 200 MB in 8.19962 s, 25.6 MB/s

13:19:19 → 200 MB in 8.19586 s, 25.6 MB/s

13:19:57 → 200 MB in 8.19967 s, 25.6 MB/s

13:20:35 → 200 MB in 8.20067 s, 25.6 MB/s

13:21:13 → 200 MB in 8.20067 s, 25.6 MB/s

........

Auffällig: Über mehrere Minuten hinweg kein einziger Timeout oder Hänger, aber die Schreibrate liegt bei jedem einzelnen Durchlauf nahezu exakt bei 25,6 MB/s praktisch identisch bis auf hundertstel Sekunden. Das spricht für mich eher gegen eine sporadisch versagende Festplatte und eher für eine konstante Drosselung/Obergrenze auf Höhe des Hosts bzw. der Storage-Anbindung, die im Rettungssystem wie im Produktivsystem gleichermaßen greift.

Zum Vergleich: Auf demselben System hatte ich vor dem Auftreten der Probleme 381 MB/s Schreiben und 564 MB/s Lesen gemessen. Also aktuell nur etwa 15x der ursprünglichen Leistung.

Da dieser Test völlig unabhängig von meinem eigenen Betriebssystem/meiner Konfiguration lief (reines Rettungssystem, keine eigene Software aktiv) und trotzdem eine derart konstante, deutlich reduzierte Rate zeigt, gehe ich davon aus, dass das Problem auf Höhe des Hosts bzw. der Storage-Anbindung liegt.

Ein normaler docker compose pull/up für 9 Container hat den Hänger erneut ausgelöst, obwohl die Baseline-Schreibrate im Rettungssystem stabil bei 25,6 MB/s lag. Das zeigt: Schon moderate I/O-Lastspitzen bringen das System aktuell zuverlässig zum Kippen. Die verbleibende Kapazität scheint kritisch knapp. Das untermauert nochmal, dass hier kein Bedienfehler deinerseits vorliegt, sondern die Storage-Anbindung schlicht nicht für normalen Betrieb ausreicht.

Leider ignoriert der Netcup-Support seit über zwei Tagen mein Ticket.

Update:

Ich habe zwischenzeitlich die im Kontrollpanel angebotene Speicher-Optimierung selbst durchgeführt. Das hat die zuvor gemessene, stark reduzierte Schreibrate kurzzeitig deutlich verbessert. Von ca. 20-27 MB/s zurück auf ca. 260-400 MB/s, was meine bisherigen Vergleichswerte (381 MB/s Schreiben) wieder bestätigt hat.

Das eigentliche Problem ist damit aber nicht gelöst: Kurz danach kam es unter normaler, alltäglicher I/O-Last erneut zu einem kompletten Systemausfall. Diesmal zeigten sich kernelseitige "hung_task"-Meldungen für blockierte Prozesse über mehrere Minuten, der Server war inklusive Terminal/Konsole komplett nicht mehr erreichbar. Einziger Weg zurück: harter Reset über die Kontrollseite.

Nach jedem solchen erzwungenen Reset entstehen erneut Dateisystem-Inkonsistenzen (Block-Bitmap-Differenzen, falsche Frei-Zähler, Checksum-Fehler), die ich jeweils über das Rettungssystem mit fsck reparieren musste.Bislang zweimal erfolgreich, aber eben nur als Reparatur der Folgeschäden, nicht der eigentlichen Ursache.

Die Optimierung hat nur den Durchsatz kurzfristig verbessert, die grundsätzliche Instabilität des Systems unter normaler Last besteht weiterhin. Ich sehe an diesem Punkt keine andere sinnvolle Lösung mehr als eine Migration auf ein anderes Host-System. Eeine weitere Optimierung oder erneute Diagnose am aktuellen Host wird das Problem meiner Einschätzung nach nicht dauerhaft beheben, da es trotz bereits erfolgter Maßnahmen wiederholt in derselben Form zurückkommt.

Der Netcup-Support scheint mein Ticket bisher komplett zu ignorieren.