Ik schrijf dit niet als een negatieve review van AVA Hosting.
Het is gewoon een van mijn werkdagen als developer: een server gedraagt zich slecht, de voor de hand liggende verklaringen passen niet, en uiteindelijk laat Linux zien wat er werkelijk gebeurt.
Ik had een kleine KVM-VPS bij AVA Hosting met:
1 vCPU
2 GB RAM
25 GB NVMeDaarop draaide een normale productieworkload. Nginx draaide. De backend draaide. Er was geheugen beschikbaar. De schijf was niet vol.
Toch kon de server het werk niet bijhouden.
Daarom voerde ik gedurende 60 seconden een passieve meting uit onder normaal productieverkeer. Geen stresstest, geen synthetische HTTP-flood en geen diskbenchmark.
Het resultaat:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11De beslissende waarde was 32,73% CPU steal. Vanaf dat moment veranderde de diagnose volledig.
Waarom dit mij verbaasde
AVA Hosting adverteert zijn VPS-product momenteel met de tekst “Guaranteed resources — no sharing”. Op de VPS-pagina's wordt de vCPU-toewijzing ook omschreven als vast of dedicated, en prestaties zouden niet door andere klanten moeten worden beïnvloed. In de Linux VPS-informatie gaat AVA nog verder: een CPU-intensieve workload van een andere tenant op dezelfde host zou geen steal time in jouw instance kunnen veroorzaken. Op een andere pagina staat dat CPU steal op hypervisorniveau wordt geëlimineerd.
Dat zijn zeer specifieke claims. Dit was niet simpelweg een VPS-pagina met 1 vCPU zonder uitleg over het CPU-toewijzingsmodel. AVA adverteerde expliciet bescherming tegen precies het soort CPU-contention dat Linux in mijn VM leek te rapporteren.
Wat CPU steal betekent
steal is een normale Linux-CPU-metriek in gevirtualiseerde omgevingen. Het staat voor CPU-tijd waarin de guest uitvoerbaar werk had, maar de virtuele CPU feitelijk niet draaide.
Dat is iets anders dan een applicatie die gewoon alle beschikbare CPU gebruikt. Als ik ongeveer 100% user/system, 0% steal en 0% idle had gezien, zou ik hebben geconcludeerd dat mijn workload simpelweg meer rekenkracht nodig had.
Hier bestond ongeveer een derde van de CPU-accounting uit steal.
Vanuit de guest kan ik AVA's hypervisor niet zien. Ik ken de belasting van de fysieke node, het aantal naburige VM's, het CPU-pinningbeleid of de overcommit-ratio niet. Wat ik wel kan zien, is wat Linux aan mijn VM rapporteerde: de vCPU draaide herhaaldelijk niet terwijl er werk klaarstond.
Het was geen piek van één seconde
Eén slechte CPU-sample zou mij niet overtuigen. Daarom mat ik de machine 60 seconden lang continu. Ik draaide bewust geen stresstest, synthetische HTTP-flood of diskbenchmark.
De metingen per seconde zagen er herhaaldelijk zo uit:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00Tegen het einde van de observatie was hetzelfde patroon nog aanwezig:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00Het volledige gemiddelde:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%Dit was dus geen korte scheduling-anomalie. Gedurende het grootste deel van de minuut bleef steal rond de 30% of hoger, terwijl CPU idle op nul bleef staan.
Ter illustratie: 32,73% van één minuut is ongeveer 19,64 seconden. Dat betekent niet dat de VPS 19,64 seconden achter elkaar bevroor; de kleinere intervallen waarin de vCPU niet werd ingepland telden samen op tot ongeveer die hoeveelheid tijd.
De backend kon de achterstand niet wegwerken
Het CPU-probleem was ook op applicatieniveau zichtbaar. Voor de observatie stond de listen queue van de backend op:
Recv-Q: 168
Send-Q: 511Na 60 seconden:
Recv-Q: 166
Send-Q: 511De exacte cijfers zijn niet belangrijk. Belangrijk is dat de queue praktisch niet leegliep. De applicatie had een volle minuut om bij te komen en bleef toch achterlopen.
Er waren ook veel CLOSE-WAIT-verbindingen. Alleen daarvoor zou ik de host niet verantwoordelijk stellen, omdat applicatie-side connection handling dit eveneens kan veroorzaken. Maar het totaalbeeld was consistent:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingDe server leefde, maar was niet gezond.
RAM en schijf waren niet de voor de hand liggende bottlenecks
Ik controleerde de gebruikelijke alternatieven. Het geheugen:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBEr was nog flink wat geheugen beschikbaar en er was geen duidelijke OOM-gebeurtenis die het gedrag verklaarde.
Het bestandssysteem:
24 GB total
14 GB used
9.4 GB available
60% usedDe gemiddelde CPU I/O wait was 0.00%. Ondertussen bleef CPU pressure rond de 99%, lag de load average op ongeveer 3,5–4 op een VM met één vCPU en bereikte de runnable queue 11.
Alle metingen wezen dezelfde kant op: de machine kwam CPU-tijd tekort en zat niet duidelijk vast op RAM of storage.
De tegenstelling met AVA's eigen formulering
Dit vind ik het interessantste deel.
AVA zegt “Guaranteed resources — no sharing”. Prestaties zouden niet door andere klanten moeten worden beïnvloed. De Linux VPS-informatie zegt dat een andere tenant geen steal time kan veroorzaken, en op een andere pagina staat dat CPU steal op hypervisorniveau wordt geëlimineerd.
Mijn AVA-VPS rapporteerde:
Average CPU steal: 32.73%Vanuit de VM kan ik niet bewijzen waarom dit precies gebeurde. Ik kan geen opzettelijke overselling aantonen, geen specifieke naburige workload aanwijzen en AVA's host-side CPU-configuratie niet reconstrueren.
Ik beweer ook niet dat iedere VPS van AVA Hosting zich zo gedraagt. Ik heb één VPS getest.
Maar ik kan wel zeggen dat het gedrag dat ik heb gemeten erg moeilijk te rijmen is met deze specifieke claims over CPU-isolatie. Voor dit artikel is dat genoeg.
Waarom ik niet heb geüpgraded
De voor de hand liggende reactie zou zijn geweest om meer vCPU's te kopen.
Als de VPS vrijwel geen steal had laten zien en mijn applicatie simpelweg één volledige core gebruikte, zou een upgrade logisch zijn geweest. Maar ongeveer een derde van de gemeten CPU-accounting bestond uit steal.
Ik wilde niet betalen voor extra virtuele CPU's voordat ik begreep waarom zo'n groot deel van de uitvoeringstijd van de eerste vCPU al als niet beschikbaar werd gerapporteerd. Daarom heb ik de VPS opgezegd en om restitutie gevraagd.
AVA betaalde alles snel terug
Dit deel van de ervaring was goed.
AVA Hosting heeft het volledige bedrag terugbetaald. De restitutie werd snel afgehandeld en ze gingen niet dagenlang met mij in discussie over de CPU-metingen. Ik legde het probleem uit, vroeg mijn geld terug en kreeg het terug.
Dat waardeer ik.
Mijn ervaring levert daarom twee afzonderlijke conclusies op: de VPS die ik kreeg had een ernstig probleem met CPU-beschikbaarheid, en AVA handelde mijn restitutie correct af. Beide zijn waar.
Wat ik hiervan heb geleerd
Ik beoordeel een VPS niet meer alleen op specificaties zoals 1 vCPU / 2 GB RAM / NVMe / KVM. Die cijfers vertellen wat er is geprovisioned, maar niet hoe voorspelbaar CPU onder echte belasting beschikbaar is.
Een van de eerste dingen die ik tegenwoordig op een nieuwe VM controleer:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60De nuttigste les uit mijn ervaring met AVA Hosting was niet dat één vCPU per definitie te weinig is. Het was dat een draaiend proces, beschikbaar RAM en een gezond ogende schijf een heel ander probleem kunnen verbergen.
In mijn geval maakte Linux dat ongewoon duidelijk:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting adverteert CPU-resources zonder sharing en zegt dat steal door naburige workloads niet zou moeten voorkomen. Mijn VPS rapporteerde iets anders.
Ik zegde hem op. AVA betaalde al mijn geld snel en zonder discussie terug.
Daar eindigde deze debuggingdag.