Mein FDCServers-VPS lief bei mehr als 3 TB Traffic problemlos. Dann dauerten Lesezugriffe plötzlich 18 Sekunden

Ich schreibe das hier nicht als negative Bewertung von FDCServers. Ich möchte niemandem sagen, ob er dort einen VPS kaufen sollte oder nicht. Ich hatte einen Server, einen Workload und eine konkrete Folge von Problemen. Das reicht nicht, um einen ganzen Hosting-Anbieter zu beurteilen.

Es ist einfach eine Geschichte aus meinem Entwickleralltag. Der VPS lief eine Zeit lang normal und hatte bereits mehr als 3 TB Traffic übertragen. Dann verursachte die gewöhnliche Last plötzlich massive Verzögerungen. Seiten brauchten sehr lange für eine Antwort oder liefen vollständig in einen Timeout. Zunächst kamen die üblichen Verdächtigen infrage: Anwendung, Nginx, Arbeitsspeicher, Netzwerk, Connection-Limits oder zu hohe Last. Die Linux-Metriken zeigten jedoch in eine andere Richtung.

Der VPS war nicht von Anfang an langsam

Zwischen den Vorfällen konnte die Maschine völlig gesund aussehen. In einer unauffälligen Phase gab es keine Prozesse im D-state, CPU-iowait lag bei ungefähr 0%, die Disk-Latenz bei etwa 2–4 ms und der I/O-PSI praktisch bei null:

D-state processes: 0
CPU iowait:        ~0%
disk latency:      ~2–4 ms
I/O PSI some:      0.04
I/O PSI full:      0.04

Hätte ich mich nur in diesem Moment eingeloggt und top, free -h, df -h sowie systemctl status nginx geprüft, hätte ich den VPS vermutlich für gesund gehalten. Dann kam die normale Last zurück und der Zustand der Maschine änderte sich drastisch.

18,7 Sekunden für einen Read änderten die Richtung der Untersuchung

Eines der aussagekräftigsten iostat-Samples sah so aus:

r_await = 18744 ms
f_await = 53561 ms
aqu-sz  = 128.54
util    = 100.10%
read    = 88 KB/s

Entscheidend ist die Kombination. Abgeschlossene Reads benötigten im Mittel rund 18,7 Sekunden. Die Flush-Latenz lag bei etwa 53,6 Sekunden. Die durchschnittliche I/O-Queue lag über 128, während der nutzbare Lesedurchsatz nur 88 KB/s betrug. Das war nicht einfach ein beschäftigter Datenträger, der große Datenmengen bewegte. Der Storage-Pfad verbrachte enorme Zeit damit, auf den Abschluss von Operationen zu warten.

iowait und PSI zeigten systemweiten I/O-Druck

In den schlimmsten Phasen zeigte vmstat 4–9 blockierte Prozesse, 97–100% CPU-iowait und 0% CPU idle. iowait bedeutet nicht, dass die Anwendung die gesamte CPU verbraucht. Es bedeutet, dass nutzbare Arbeit auf ausstehende I/O-Operationen wartet.

Linux Pressure Stall Information machte das Bild noch deutlicher:

I/O PSI some avg10 = 99.14
I/O PSI full avg10 = 95.55

Bei späteren Reproduktionen näherte sich full 98%. Die Disk-Auslastung sagt mir, dass ein Gerät beschäftigt ist. PSI sagt mir, wie stark der Workload durch die Ressource tatsächlich ausgebremst wird. Dauerhafter I/O-Druck von 95–98% ist keine kleine Performance-Abweichung.

D-state und Kernel-Stacks zeigten unterhalb der Anwendung

Danach prüfte ich, welche Prozesse blockiert waren. Gleichzeitig sah ich jbd2, systemd-journald, Nginx-Worker, Nginx-Cache-Prozesse und weitere Dateisystemaktivität im D-state. Wäre nur meine Anwendung hängen geblieben, hätte ich die Anwendung untersucht. Wenn aber Nginx, System-Journal und EXT4-Journal gleichzeitig blockieren, ist Storage die offensichtliche gemeinsame Abhängigkeit.

Die EXT4-Journaling-Pfade enthielten:

wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transaction

Nginx-Worker warteten in gewöhnlichen Datei-Leseoperationen:

folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64

Zu einem Zeitpunkt meldete der Kernel, dass ein Nginx-Task länger als 122 Sekunden blockiert war. Nginx konnte weiterhin als active erscheinen, doch das bedeutete nicht, dass seine Worker sinnvolle Arbeit abschließen konnten. running und gesund sind zwei verschiedene Zustände.

Eine Backend-Antwort in 3 ms trennte die Anwendung vom Dateisystempfad

Der sauberste Vergleich war Nginx gegen das lokale Anwendungs-Backend. Anfragen über Nginx endeten mit HTTP=000 und Connection- oder TLS-Timeouts. Eine direkte Anfrage an das Backend war dagegen in etwa 3 ms abgeschlossen:

connect = 0.000423 s
TTFB    = 0.003063 s
total   = 0.003139 s

Der konkrete HTTP-Status war für diesen Test nicht entscheidend. Das Backend nahm die Verbindung an, verarbeitete die Anfrage und lieferte fast sofort eine Antwort. Gleichzeitig waren Nginx-Worker sichtbar in EXT4-Reads blockiert. Damit ließ sich normale Anwendungsausführung klar vom dateisystemabhängigen Pfad davor trennen.

Der Fehler war reproduzierbar und konnte wieder verschwinden

Vor einer Reproduktion sah die Maschine normal aus:

HTTP:          200
D-state:       0
CPU iowait:    3%
r_await:       ~1.18 ms
I/O PSI full:  ~2.95%

Rund eine halbe Minute später:

D-state:       4
CPU iowait:    91%
CPU idle:      0%
I/O PSI some:  86.11%
I/O PSI full:  78.02%
r_await:       236.50 ms
HTTP:          000

Später erreichte CPU-iowait 96–100%, I/O PSI full näherte sich 98%, die HTTPS-Queue erreichte 512 und die HTTP-Checks schlugen weiterhin fehl. Das war wesentlich aussagekräftiger als die Aussage, der VPS fühle sich langsam an.

Nach dem Entfernen des Workloads konnte der umgekehrte Übergang schnell stattfinden:

D-state:      0
CPU iowait:   6%
r_await:      ~0.98 ms
queue depth:  ~0.07
HTTP:         200

Genau deshalb sind intermittierende Storage-Probleme im Nachhinein schwer zu untersuchen. Ein Anbieter kann den Server nach der Erholung prüfen und tatsächlich normale Latenzen sehen. Das erklärt aber nicht, was zehn Minuten vorher passiert ist. Exakte UTC-Zeitstempel wurden deshalb unverzichtbar.

Zwei irreführende Metriken: await=0 und freier Speicherplatz

In einigen schlechten Intervallen sah ich r_await = 0, obwohl iowait hoch war, Prozesse im D-state standen, Requests weiterhin in flight waren und fast keine Reads abgeschlossen wurden. Latenzstatistiken basieren auf abgeschlossenen I/O-Operationen. Bleibt eine Operation hängen und endet im Messintervall nicht, kann sie nicht in die Latenz abgeschlossener Operationen eingehen. Eine Null bedeutet daher nicht zwangsläufig einen sofort reagierenden Datenträger.

Ich prüfte auch den Füllstand des Dateisystems. Später war es voller, als ich es normalerweise zulassen würde. Derselbe Fehlertyp war jedoch bereits aufgetreten, als das Root-Dateisystem nur ungefähr zu 24% belegt war. Zu diesem Zeitpunkt waren rund 1,2 GiB RAM verfügbar, die Inode-Auslastung lag bei etwa 5% und das Netzwerkinterface zeigte weder Fehler noch verworfene Pakete. Der Füllstand allein konnte den gesamten Vorfall nicht erklären.

Was ich beweisen konnte und was nicht

Aus dem VPS heraus konnte ich Anwendung, Linux VFS, EXT4 und das virtuelle Blockgerät beobachten. Danach beginnt die Infrastruktur des Anbieters: Virtualisierung, verteilter Storage, Storage-Netzwerk, physische Geräte, Scheduling und weitere Ebenen, die ich aus dem Guest nicht einsehen kann.

Deshalb kann ich nicht seriös behaupten, dass eine bestimmte physische SSD defekt war, oder einen bestimmten Storage-Node, Netzwerkpfad oder Virtualisierungskomponente als Root Cause benennen.

Was ich sagen kann, ist enger gefasst und gut belegt: Der meinem Linux-Guest präsentierte virtuelle Storage-Pfad geriet wiederholt in Zustände, in denen gewöhnliche Dateisystem-I/O mehrere Sekunden benötigte oder nicht innerhalb eines vernünftigen Zeitraums abgeschlossen wurde. Die Belege kamen aus iostat, PSI, D-state, Kernel-Wait-Stacks, EXT4/jbd2-Waits, Nginx-Dateisystem-Waits, Queue-Tiefe und Request-Timings. Für meine technische Diagnose war das ausreichend, für eine physische Root Cause nicht.

Warum mehr als 3 TB vorheriger Traffic den späteren Stalls nicht widersprechen

Das hat mich zunächst verwirrt. Wenn Storage Probleme hatte, wie konnte der VPS zuvor mehrere Terabyte erfolgreich übertragen?

Weil Netzwerktraffic nicht dasselbe ist wie physische Disk-I/O. Eine Datei kann einmal aus dem Backing Storage gelesen werden, im Linux Page Cache bleiben und anschließend vielfach aus dem Arbeitsspeicher ausgeliefert werden. Drei Terabyte Netzwerktraffic bedeuten daher nicht drei Terabyte einmaliger physischer Lesezugriffe.

Außerdem verändern sich Infrastrukturbedingungen: Cache-Zustand, Storage-Last, Queueing, Host-Platzierung und andere Workloads können wechseln. Ein VPS, der gestern normal lief, garantiert heute nicht dasselbe Storage-Verhalten.

Irgendwann hörte ich auf, auf eine tiefere Root Cause zu warten

Ich sammelte exakte Zeitstempel, vmstat, iostat, PSI, Snapshots blockierter Prozesse, Kernel-Stacks, Dateisystem-Waits, Queue-Tiefen und HTTP-Timings. Ich schickte die Diagnosen an FDCServers und wartete auf eine tiefergehende Erklärung auf Infrastrukturebene.

Ich wartete lange. Irgendwann hörte ich auf. Aus meiner Sicht wusste ich bereits genug für eine operative Entscheidung: Das Problem war reproduzierbar, schwerwiegend, unterhalb der Anwendung sichtbar, und die physische Ursache lag außerhalb dessen, was ich aus meinem VPS sehen konnte.

Ich bat um eine Rückerstattung, und FDCServers zahlte das Geld zurück

Ich schickte FDCServers eine Zusammenfassung der Probleme und meiner Diagnosedaten, bat um Kündigung des Dienstes und verlangte eine Rückerstattung. Das Geld wurde zurückerstattet.

Die Geschichte endet also nicht mit einem langen Streit ums Geld. Ich wartete auf eine endgültige technische Erklärung, entschied irgendwann, nicht länger zu warten, schickte meine Belege und bat um mein Geld zurück. FDCServers erstattete es.

Was ich danach geändert habe

Der nützliche Teil dieser Erfahrung war nicht die Entscheidung, ob ein Hoster gut oder schlecht ist. Sie hat verändert, wie ich langsame Linux-Server untersuche.

Grundlegende Befehle wie top, free -h und df -h nutze ich weiterhin, aber diese kommen heute deutlich früher:

date -u
uptime
cat /proc/pressure/io
cat /proc/pressure/memory
cat /proc/pressure/cpu
vmstat 1 10
iostat -x 1 10
ps -eo state,pid,ppid,etime,wchan:50,comm,args | awk 'NR==1 || $1 ~ /^D/'
ss -lntp
journalctl -k --since '30 min ago' --no-pager

Wenn möglich, teste ich außerdem einzelne Request-Pfade getrennt: öffentliche Anfrage, lokales Nginx, direktes Backend, Dateisystem und Block-Device-Metriken. Die Frage lautet nicht mehr nur, warum der Server langsam ist, sondern: Auf welcher Ebene hört nützliche Arbeit auf, abgeschlossen zu werden?

Wenn möglich, sichere ich die Belege vor einem Reboot. Ein Neustart kann den Dienst wiederherstellen, aber zugleich genau den D-state, PSI, die Queues und die Latenzen beseitigen, die einen intermittierenden Vorfall diagnostizierbar machen.

Zum Schluss

Ich kaufte keinen FDCServers-VPS, weil ich Material für einen Hosting-Artikel suchte. Ich wollte einen Server mit viel Bandbreite. Eine Zeit lang bekam ich genau das: Er verarbeitete reale Last und übertrug mehr als drei Terabyte.

Dann führte normale Last reproduzierbar zu iowait bis 100%, I/O PSI nahe 100%, Reads bis 18,7 Sekunden, Flush-Latenzen über 53 Sekunden, großen Queues, in Dateisystem-Reads blockiertem Nginx und auf I/O wartendem EXT4/jbd2.

Ich habe nie erfahren, welche physische oder hostseitige Komponente die Ursache war, und ich muss auch nicht so tun, als wüsste ich es. Ich identifizierte die Ebene, auf der der Fehler sichtbar wurde, sammelte genügend Belege, um ihn von einem Anwendungsproblem zu unterscheiden, hörte auf, auf eine tiefere Erklärung zu warten, und verlangte mein Geld zurück. FDCServers erstattete es.

Das ist kein Urteil über jeden FDCServers-VPS. Es ist eine gut dokumentierte Erinnerung daran, dass ein Dienst active und ein Prozess running aussehen kann, während die Maschine fast ihre gesamte nutzbare Zeit auf Storage wartet.