Ik schrijf dit niet als een negatieve review van FDCServers. Ik probeer ook niemand te vertellen of die daar wel of geen VPS moet kopen. Ik had één server, één workload en één specifieke reeks problemen. Dat is niet genoeg om een volledig hostingbedrijf te beoordelen.
Dit is gewoon een verhaal uit mijn dagelijkse werk als developer. De VPS had een tijdlang normaal gewerkt en al meer dan 3 TB aan verkeer verwerkt. Daarna begon een gewone workload plots enorme vertragingen te veroorzaken. Pagina's konden zeer lang op een response wachten of volledig in een timeout lopen. Eerst verdacht ik de gebruikelijke zaken: de applicatie, Nginx, geheugen, netwerk, connection limits of simpelweg te veel load. De Linux-metrics wezen ergens anders naartoe.
De VPS was niet vanaf het begin traag
Tussen incidenten door kon de machine volledig gezond lijken. Tijdens één normale periode waren er geen processen in D-state, CPU iowait was ongeveer 0%, disklatency ongeveer 2–4 ms en I/O PSI vrijwel nul:
D-state processes: 0
CPU iowait: ~0%
disk latency: ~2–4 ms
I/O PSI some: 0.04
I/O PSI full: 0.04Als ik alleen op dat moment had ingelogd en top, free -h, df -h en systemctl status nginx had bekeken, had ik waarschijnlijk geconcludeerd dat de VPS prima werkte. Daarna kwam de normale workload terug en veranderde de toestand van de machine drastisch.
Reads van 18,7 seconden veranderden het onderzoek
Een van de duidelijkste iostat-samples zag er zo uit:
r_await = 18744 ms
f_await = 53561 ms
aqu-sz = 128.54
util = 100.10%
read = 88 KB/sDeze waarden moet je samen lezen. Voltooide reads hadden gemiddeld ongeveer 18,7 seconden latency. De flush-latency was ongeveer 53,6 seconden. De gemiddelde I/O-queue was groter dan 128, terwijl de bruikbare readsnelheid slechts 88 KB/s bedroeg. Dit was niet gewoon een drukke disk die veel data verwerkte. Het storagepad bracht enorme hoeveelheden tijd door met wachten op het voltooien van operations.
iowait en PSI toonden I/O-pressure in het hele systeem
Tijdens de slechtste perioden liet vmstat 4–9 geblokkeerde processen zien, CPU iowait rond 97–100% en 0% CPU idle. iowait betekent niet dat de applicatie alle CPU verbruikt. Het betekent dat nuttig werk wacht op uitstaande I/O.
Linux Pressure Stall Information maakte het beeld nog duidelijker:
I/O PSI some avg10 = 99.14
I/O PSI full avg10 = 95.55Bij latere reproducties naderde full 98%. Disk utilization vertelt dat een device bezig is; PSI vertelt hoe ernstig de workload door die resource wordt stilgezet. Aanhoudende I/O-pressure van 95–98% is geen kleine performance-regressie.
D-state en kernel stacks wezen onder de applicatielaag
Daarna keek ik welke processen precies geblokkeerd waren. Tegelijkertijd zag ik jbd2, systemd-journald, Nginx-workers, Nginx-cacheprocessen en andere filesystemactiviteit in D-state. Als alleen mijn applicatie vastzat, zou ik de applicatie onderzoeken. Wanneer Nginx, het system journal en het EXT4-journal tegelijk blokkeren, is storage de duidelijkste gedeelde afhankelijkheid.
De EXT4-journalingpaden bevatten:
wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transactionNginx-workers wachtten in gewone file reads:
folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64Op een bepaald moment meldde de kernel dat een Nginx-task langer dan 122 seconden geblokkeerd was. Nginx kon nog steeds als active worden weergegeven, maar dat betekende niet dat de workers nuttig werk konden afronden. running en gezond zijn verschillende toestanden.
Een backendresponse van 3 ms scheidde de applicatie van het filesystempad
De duidelijkste vergelijking was die tussen Nginx en de lokale application backend. Requests via Nginx leverden HTTP=000 op door connection- of TLS-timeouts. Een directe request naar de backend was in ongeveer 3 ms klaar:
connect = 0.000423 s
TTFB = 0.003063 s
total = 0.003139 sDe exacte HTTP-status was voor deze test niet belangrijk. De backend accepteerde de verbinding, verwerkte het request en produceerde vrijwel direct een response. Tegelijk waren Nginx-workers zichtbaar aan het wachten op EXT4-reads. Daarmee kon ik normale applicatie-uitvoering scheiden van het filesystem-afhankelijke pad ervoor.
De storing was reproduceerbaar en kon ook weer verdwijnen
Vlak voor één reproductie zag de machine er normaal uit:
HTTP: 200
D-state: 0
CPU iowait: 3%
r_await: ~1.18 ms
I/O PSI full: ~2.95%Ongeveer een halve minuut later:
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: 000Later liep CPU iowait op tot 96–100%, I/O PSI full tot bijna 98%, de HTTPS-queue tot 512 en bleven HTTP-checks falen. Dat was veel bruikbaarder bewijs dan zeggen dat de VPS traag aanvoelde.
Nadat ik de workload verwijderde, kon de tegenovergestelde overgang snel plaatsvinden:
D-state: 0
CPU iowait: 6%
r_await: ~0.98 ms
queue depth: ~0.07
HTTP: 200Daarom zijn intermittente storageproblemen achteraf zo moeilijk te onderzoeken. Een provider kan de server na herstel bekijken en daadwerkelijk normale latency zien. Dat verklaart nog steeds niet wat er tien minuten eerder gebeurde. Exacte UTC-timestamps werden daarom essentieel.
Twee misleidende metrics: await=0 en vrije schijfruimte
Tijdens sommige slechte intervallen zag ik r_await = 0 terwijl iowait hoog was, processen in D-state stonden, requests in-flight bleven en bijna geen reads werden voltooid. Latencystatistieken zijn gebaseerd op voltooide I/O. Als een operation vast blijft zitten en tijdens het sample-interval niet voltooit, kan deze niet bijdragen aan de gemiddelde latency van voltooide operations. Een nul betekent dus niet altijd een instant reagerende disk.
Ik keek ook naar disk fullness. Later werd het filesystem voller dan ik normaal zou toestaan, maar hetzelfde type failure was al opgetreden toen het root filesystem slechts ongeveer 24% gebruikt was. Er was toen ongeveer 1,2 GiB RAM beschikbaar, inode usage lag rond 5% en de netwerkinterface liet geen errors of dropped packets zien. Disk fullness kon het hele incident dus niet verklaren.
Wat ik kon bewijzen en wat niet
Vanuit de VPS kon ik de applicatie, Linux VFS, EXT4 en het virtuele block device observeren. Daarna begint de infrastructuur van de provider: virtualisatie, distributed storage, storage networking, fysieke devices, scheduling en andere lagen die ik vanuit de guest niet kan inspecteren.
Ik kan daarom niet eerlijk beweren dat een specifieke fysieke SSD kapot was, of een bepaalde storage node, netwerkroute of virtualisatiecomponent als root cause aanwijzen.
Wat ik wel kan zeggen is beperkter en goed onderbouwd: het virtuele storagepad dat aan mijn Linux guest werd aangeboden, kwam herhaaldelijk in toestanden terecht waarin gewone filesystem-I/O seconden duurde of niet binnen redelijke tijd werd afgerond. Het bewijs kwam uit iostat, PSI, D-state, kernel wait stacks, EXT4/jbd2-waits, filesystem-waits van Nginx, queue depth en request timings. Dat was voldoende voor de technische diagnose die ik nodig had, maar niet voor een fysieke root cause.
Waarom meer dan 3 TB eerder verkeer de latere stalls niet tegenspreekt
Dit bracht me eerst in verwarring. Als storage problemen had, hoe kon de VPS eerder meerdere terabytes succesvol verwerken?
Omdat netwerkverkeer niet hetzelfde is als fysieke disk-I/O. Een bestand kan één keer uit backing storage worden gelezen, in de Linux page cache blijven en daarna vele malen vanuit memory worden geleverd. Drie terabyte over het netwerk betekent dus niet drie terabyte unieke fysieke disk reads.
Infrastructuurcondities veranderen bovendien met de tijd: cache state, storage load, queueing, host placement en andere workloads kunnen wijzigen. Dat een VPS gisteren normaal werkte, garandeert vandaag geen identiek storagegedrag.
Uiteindelijk stopte ik met wachten op een diepere root cause
Ik verzamelde exacte timestamps, vmstat, iostat, PSI, snapshots van geblokkeerde processen, kernel stacks, filesystem waits, queue depths en HTTP-timings. Ik stuurde de diagnostics naar FDCServers en wachtte op een diepere verklaring op infrastructuurniveau.
Ik heb lang gewacht. Uiteindelijk ben ik ermee gestopt. Vanuit mijn kant wist ik genoeg om een operationele beslissing te nemen: het probleem was reproduceerbaar, ernstig, zichtbaar onder de applicatielaag en de fysieke oorzaak lag buiten wat mijn VPS kon zien.
Ik vroeg om een refund en FDCServers betaalde terug
Ik stuurde FDCServers een samenvatting van de problemen en de verzamelde diagnostics, vroeg om de service te beëindigen en verzocht om een refund. Ze betaalden het bedrag terug.
Dit verhaal eindigt dus niet met een lang financieel gevecht. Ik wachtte op een definitieve technische verklaring, besloot niet langer te wachten, stuurde mijn bewijs en vroeg mijn geld terug. FDCServers stortte het terug.
Wat ik daarna veranderde
Het nuttige resultaat was niet bepalen of een hostingbedrijf goed of slecht is. Het veranderde hoe ik trage Linux-servers debug.
Ik gebruik nog steeds top, free -h en df -h, maar ik pak tegenwoordig veel eerder deze tools erbij:
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-pagerWaar mogelijk test ik requestpaden ook afzonderlijk: publieke request, lokale Nginx, directe backend, filesystem en block-device metrics. De vraag is niet meer alleen waarom de server traag is. De vraag is: op welke laag stopt nuttig werk met afronden?
Waar mogelijk leg ik het bewijs vast vóór een reboot. Een reboot kan de service herstellen, maar kan ook precies de D-state, PSI, queues en latency verwijderen die een intermittent incident diagnoseerbaar maken.
Tot slot
Ik kocht geen FDCServers-VPS omdat ik materiaal voor een hostingartikel wilde. Ik wilde een server met veel bandbreedte. Een tijdlang kreeg ik precies dat: hij verwerkte echte workload en verstuurde meer dan drie terabyte.
Daarna begon normale workload reproduceerbaar iowait tot 100%, I/O PSI bijna 100%, reads tot 18,7 seconden, flush-latency boven 53 seconden, grote queues, Nginx geblokkeerd in filesystem reads en EXT4/jbd2 wachtend op I/O te produceren.
Ik heb nooit geleerd welke fysieke of host-side component de oorzaak was, en ik hoef niet te doen alsof dat wel zo is. Ik identificeerde de laag waar de failure zichtbaar werd, verzamelde genoeg bewijs om het van een applicatieprobleem te onderscheiden, stopte met wachten op een diepere root-cause-uitleg en vroeg mijn geld terug. FDCServers betaalde het terug.
Dit is geen oordeel over iedere FDCServers-VPS. Het is één goed gedocumenteerde herinnering dat een service active en een proces running kan lijken, terwijl de machine bijna al haar bruikbare tijd op storage wacht.