Ik schrijf dit niet als een negatieve review van REGXA en ik probeer niemand te vertellen of hij daar wel of geen VPS moet kopen. Dit is gewoon een van mijn dagen als developer.
Ik verhuisde een normale workload naar een KVM-VPS met 2 vCPU, 2 GB RAM en 60 GB NVMe. Nginx draaide. De backend draaide. Toch gedroeg de machine zich alsof hij zwaar overbelast was: requests stapelden zich op, TLS werd traag, verbindingen bleven open en sommige requests eindigden pas na meer dan twee minuten in HTTP 504.
De CPU-accounting veranderde het onderzoek
Mijn eerste gedachte lag voor de hand: iets in de VPS verbruikte de CPU. Daarna draaide ik mpstat.
Average CPU steal: 92.58%
CPU 0 steal: 90.62%
CPU 1 steal: 94.57%
CPU user: 4.02%
CPU system: 1.47%
CPU iowait: 0.41%
CPU idle: 0.53%Losse samples lieten herhaaldelijk ongeveer 89–98% steal zien. Ook de CPU pressure was extreem:
CPU PSI some avg10: 79.47
CPU PSI some avg60: 75.32
CPU PSI some avg300: 76.31
Load average: 5.85 / 5.75 / 5.73Dit was een machine met maar twee vCPU’s. Linux had runnable processen die op CPU wachtten. De belangrijkste waarde was niet normaal CPU-gebruik door de applicatie, maar %steal.
Hoog CPU-gebruik en CPU steal zijn verschillende problemen
Als mijn applicatie de processor echt aan het belasten was, zou ik hoge waarden voor user of system verwachten. In plaats daarvan zag de VPS er ongeveer zo uit:
user: 4%
system: 1%
steal: 93%CPU steal is tijd waarin een virtuele CPU klaarstaat om te draaien, maar niet door de hypervisor wordt ingepland. Wanneer ik zeg dat er CPU-tijd van de VPS werd afgenomen, bedoel ik dat in die technische virtualisatiebetekenis. Ik kan niet bewijzen dat REGXA bewust fysieke cores die exclusief van mij waren aan een andere klant heeft toegewezen, en uit guest-metrics kun je geen intentie afleiden. Wat ik wel kan aantonen, is dat de guest herhaaldelijk werk klaar had staan zonder de benodigde CPU-schedulingtijd te krijgen.
Ik verwijderde al het productieverkeer
Er bleef een logische tegenwerping: misschien veroorzaakte mijn eigen workload het probleem. Dus haalde ik die variabele weg. Ik verplaatste de actieve workload, stopte al het productieverkeer naar deze VPS, liet de queues leeglopen en herhaalde de meting.
Average CPU steal: 94.17%
CPU 0 steal: 95.56%
CPU 1 steal: 92.83%
CPU user: 1.95%
CPU system: 0.59%
CPU iowait: 0.59%
CPU idle: 2.18%Het resultaat werd slechter. Losse vmstat-samples bleven 91–98% steal tonen, met maximaal 15 runnable processen die op CPU wachtten. De belangrijkste combinatie was:
user: 1.95%
system: 0.59%
steal: 94.17%Mijn applicaties deden nu vrijwel niets, maar de VM verloor nog steeds bijna alle schedulingtijd. Normale productielast was geen geloofwaardige verklaring meer.
Zelfs localhost werd absurd traag
Ik testte HTTPS ook via 127.0.0.1, zodat publiek DNS, mijn ISP, geografische afstand en het externe netwerkpad buiten de test vielen.
Onder verkeer mislukten vier van de tien localhost-HTTPS-pogingen tijdens de TLS-handshake. De geslaagde requests duurden 29,30, 22,77, 12,25, 11,87, 11,12 en 9,40 seconden. Sommige TLS-handshakes alleen al duurden ongeveer negen seconden.
Nadat het productieverkeer was verwijderd werd localhost sneller, maar het bleef instabiel: 0,061, 0,745, 0,830, 0,873, 1,010, 1,117, 1,121, 2,188 en 3,355 seconden. Dezelfde lokale operatie kon de ene keer ongeveer 61 ms duren en de volgende keer meer dan 3,3 seconden.
De rest van de stack liet de gevolgen zien
Op een bepaald moment zag ik ongeveer 450 established connections, 122 orphaned connections, 110 FIN-WAIT-1 en 33 CLOSE-WAIT. De listen queue van de lokale backend liep op tot ongeveer 14–15, terwijl HTTPS rond de 40 bereikte.
Nginx logde HTTP 504-responses na 142,857, 138,902, 135,064, 129,819 en 128,657 seconden. Andere requests bleven ongeveer 67–130 seconden open. Ik zag ook secure-connect timeouts van circa 35–41 seconden, database network timeouts en vertraagde TLS-operaties.
Afzonderlijk konden die symptomen eruitzien als losse problemen met Nginx, de database, het netwerk of de backend. Maar langere timeouts creëren geen CPU-tijd die de hypervisor niet inplant.
RAM en schijf konden het niet verklaren
De VPS had nog ongeveer 1,0–1,1 GiB RAM beschikbaar, vrijwel geen swapgebruik, geen OOM-events en geen activiteit van de OOM-killer. Het bestandssysteem was slechts ongeveer 20% gevuld, met circa 44 GB vrij. I/O wait bleef onder 1% tijdens de belangrijkste CPU-metingen.
Het geheugen was niet op, de schijf was niet vol en mijn applicaties verbruikten de ontbrekende CPU niet. De dominante metric bleef %steal.
Een gezonde KVM-VPS zag er compleet anders uit
Ik draaide hetzelfde soort diagnose op een andere KVM-VPS die op dat moment normaal productieverkeer verwerkte:
Average CPU steal: 0.02%
CPU idle: 87.86%
CPU PSI avg10: 0.29
CPU PSI avg60: 0.63
CPU PSI avg300: 0.49
Load average: 0.47 / 0.33 / 0.14De tien localhost-HTTPS-requests waren binnen ongeveer 37–69 ms klaar. Later mat ik op een andere daadwerkelijk drukke productie-VPS 61,71% user CPU, 5,08% system CPU, 24,09% idle en slechts 0,13% steal.
Dat onderscheid vind ik nu belangrijk. Een VPS kan druk zijn omdat mijn software de processor echt gebruikt. Dat is iets totaal anders dan een guest die meer dan 90% van de gemeten CPU-tijd op de hypervisor wacht.
REGXA bevestigde uiteindelijk contention in de infrastructuur
Vanuit de VM kon ik de guest meten, maar niet de fysieke host, schedulerconfiguratie, CPU-quota of naburige VM’s zien. REGXA kon dat wel.
Support vertelde uiteindelijk dat de VPS op shared CPU infrastructure draaide, dat CPU-resources tussen meerdere virtuele machines werden gedeeld en dat performance kon variëren afhankelijk van de belasting van de fysieke node. Ze zeiden bovendien dat de infrastructuur in Frankfurt op dat moment bijzonder veel vraag kende en schreven mijn hoge CPU steal expliciet toe aan resource contention on the underlying infrastructure.
Ze gaven ook aan dat ze de CPU-quota of scheduling policies niet konden aanpassen en geen extra dedicated CPU-resources konden toewijzen aan deze shared VPS op de huidige infrastructuur. De voorgestelde technische oplossing was verhuizing naar een locatie met lagere utilization.
Dat vond ik moeilijk te rijmen met taal die ik eerder had gezien over dedicated CPU cores en guaranteed resources. Ik kan de exacte hostconfiguratie niet zien, dus ik kan niet zeggen of het directe mechanisme CPU overcommitment, quota, scheduler weighting, throttling of een combinatie daarvan was. Intentie kan ik evenmin bewijzen. Dat hoeft ook niet: Linux liet langdurig 92–94% steal zien en REGXA zelf koppelde die hoge waarde aan contention op de gedeelde infrastructuur.
Ook de terugbetaling vergde extra volharding
Toen het infrastructuurprobleem duidelijk was, wilde ik de VPS niet blijven verhuizen en andere nodes testen. Ik wilde de dienst opzeggen en mijn geld terug.
Aanvankelijk kreeg ik alleen een gedeeltelijk bedrag aangeboden, en de voorgestelde terugbetaling zou op mijn REGXA-accountbalans komen in plaats van terug op de kaart waarmee ik had betaald. Voor mij is provider credit geen gelijkwaardige terugbetaling als ik de dienst juist wil verlaten.
Dus bleef ik reageren en vroeg ik om 100% van de betaling terug te storten naar de oorspronkelijke betaalmethode. Uiteindelijk ging REGXA akkoord en werd het volledige bedrag teruggestort naar de oorspronkelijke betaalmethode. De volledige refund werd als uitzondering omschreven.
Ik waardeer dat uiteindelijk alles is terugbetaald. Maar dat ik na de erkenning van infrastructure contention alsnog moest blijven aandringen op de financiële afhandeling, hoort eveneens bij mijn ervaring.
De les die ik eraan overhield
De makkelijkste fout zou zijn geweest om mijn applicatie te blijven optimaliseren. Ik had Nginx kunnen aanpassen, timeouts verhogen, concurrency verlagen, retries toevoegen, MongoDB onderzoeken of backendcode herschrijven. Sommige symptomen waren dan misschien veranderd. Geen daarvan zou de belangrijkste vraag beantwoorden: waarom lag CPU steal boven 90%?
Tegenwoordig stop ik niet meer zodra SSH werkt, Nginx start en een health endpoint 200 teruggeeft. Op een nieuwe VPS kijk ik ook naar %user, %system, %iowait, %idle, %steal, CPU PSI, de run queue en localhost-latency.
En als iets verdacht lijkt, verwijder ik de workload en meet ik opnieuw. In dit geval leverde dat de duidelijkste meting van het hele incident op:
CPU user: 1.95%
CPU system: 0.59%
CPU steal: 94.17%Ik beweer niet dat elke REGXA-VPS zich zo gedraagt. Ik heb één VPS getest en vastgelegd wat daarmee gebeurde. Op die machine was het bewijs echter uitzonderlijk duidelijk: mijn applicaties gebruikten nauwelijks CPU terwijl Linux aangaf dat het overgrote deel van de virtuele CPU-tijd verloren ging aan wachten op scheduling door de hypervisor. REGXA koppelde datzelfde gedrag later aan resource contention op de gedeelde infrastructuur.
Daarom leg ik het vast. Niet als score of aanbeveling, maar simpelweg als een dag uit mijn leven als developer — en als een metric die ik op een VPS nooit meer zal negeren.