Mein AVA-Hosting-VPS hatte trotz „Garantierte Ressourcen — kein Sharing“ durchschnittlich 32,73 % CPU-Steal

Ich schreibe das hier nicht als negative Bewertung von AVA Hosting.

Es ist einfach einer dieser Arbeitstage als Entwickler: Ein Server verhält sich schlecht, die naheliegenden Erklärungen passen nicht, und irgendwann zeigt Linux ziemlich deutlich, was passiert.

Ich hatte einen kleinen KVM-VPS bei AVA Hosting mit:

1 vCPU
2 GB RAM
25 GB NVMe

Darauf lief eine normale Produktionslast. Nginx lief. Das Backend lief. Arbeitsspeicher war verfügbar. Die Platte war nicht voll.

Trotzdem kam der Server mit der Last nicht hinterher.

Also beobachtete ich ihn 60 Sekunden lang passiv unter realem Produktionsverkehr. Kein Stresstest, kein künstlicher HTTP-Flood, kein Disk-Benchmark.

Das Ergebnis:

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: 11

Die entscheidende Zahl war 32,73 % CPU-Steal. Damit änderte sich die Diagnose grundlegend.

Warum mich das überrascht hat

AVA Hosting bewirbt seine VPS derzeit mit der Aussage “Guaranteed resources — no sharing”. Auf den VPS-Seiten ist außerdem von festen beziehungsweise dedizierten vCPU-Ressourcen die Rede, und die Performance soll nicht von anderen Kunden beeinflusst werden. Bei den Linux-VPS geht AVA noch weiter: Eine CPU-intensive Last eines anderen Tenants auf demselben Host soll keinen Steal Time in der eigenen Instanz verursachen können. Auf einer weiteren Seite heißt es, CPU-Steal werde bereits auf Hypervisor-Ebene eliminiert.

Das sind sehr konkrete Aussagen. Es war also nicht einfach nur eine Produktseite, auf der 1 vCPU steht, ohne zu erklären, wie CPU-Ressourcen verteilt werden. AVA bewirbt ausdrücklich Schutz vor genau der Art von CPU-Contention, die Linux in meiner VM zu melden schien.

Was CPU-Steal bedeutet

steal ist eine normale Linux-CPU-Metrik für virtualisierte Umgebungen. Sie beschreibt CPU-Zeit, in der der Gast ausführbare Arbeit hatte, die virtuelle CPU aber tatsächlich nicht lief.

Das ist etwas anderes als eine Anwendung, die einfach ihre gesamte CPU-Kapazität verbraucht. Hätte ich ungefähr 100 % user/system, 0 % steal und 0 % idle gesehen, wäre meine Schlussfolgerung gewesen: Die Anwendung braucht schlicht mehr Rechenleistung.

Hier entfiel jedoch ungefähr ein Drittel der CPU-Zeit auf Steal.

Aus der VM heraus kann ich AVAs Hypervisor nicht sehen. Ich kenne weder die Auslastung des physischen Hosts noch die Zahl benachbarter VMs, die CPU-Pinning-Strategie oder den Overcommit-Faktor. Was ich sehen kann, ist das, was Linux meiner VM meldete: Die vCPU lief wiederholt nicht, obwohl ausführbare Arbeit wartete.

Das war kein einmaliger Ausschlag

Ein einzelner schlechter CPU-Messwert hätte mich kaum überzeugt. Deshalb habe ich den Server 60 Sekunden lang kontinuierlich beobachtet. Ich habe bewusst keinen Stresstest, keinen synthetischen HTTP-Flood und keinen Disk-Benchmark gestartet.

Die sekündlichen Messwerte sahen wiederholt so aus:

%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.00

Gegen Ende der Messung war das Muster weiterhin vorhanden:

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.00

Der Durchschnitt über den gesamten Zeitraum:

user:       52.52%
system:      8.07%
softirq:     6.69%
steal:      32.73%
iowait:      0.00%
idle:        0.00%

Das war also keine kurze Scheduling-Anomalie. Während des größten Teils der Minute lag Steal bei ungefähr 30 % oder darüber, während CPU-Idle bei null blieb.

Zur Einordnung: 32,73 % einer Minute entsprechen rund 19,64 Sekunden. Das bedeutet nicht, dass der VPS 19,64 Sekunden am Stück eingefroren war. Vielmehr summierten sich viele kleinere Zeitabschnitte, in denen die vCPU nicht eingeplant wurde, auf ungefähr diesen Wert.

Das Backend konnte den Rückstand nicht aufholen

Das CPU-Problem war auch auf Anwendungsebene sichtbar. Vor der Messung zeigte die Listen-Queue des Backends:

Recv-Q: 168
Send-Q: 511

Nach 60 Sekunden:

Recv-Q: 166
Send-Q: 511

Die exakten Zahlen sind nicht entscheidend. Entscheidend ist, dass die Queue praktisch nicht abgebaut wurde. Die Anwendung hatte eine volle Minute Zeit, aufzuholen, blieb aber weiterhin zurück.

Es gab außerdem viele CLOSE-WAIT-Verbindungen. Allein dafür würde ich den Host nicht verantwortlich machen, denn dieser Zustand kann auch mit der Verbindungsbehandlung der Anwendung zusammenhängen. Das Gesamtbild war jedoch konsistent:

1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not draining

Der Server lief, aber er war nicht gesund.

RAM und Speicher waren nicht die offensichtlichen Engpässe

Ich prüfte auch die üblichen Alternativen. Beim Arbeitsspeicher sah es so aus:

RAM total:      ~1.9 GiB
RAM available:  ~959 MiB
Swap total:     2 GiB
Swap used:      ~33 MiB

Es war also noch reichlich Speicher verfügbar, und es gab kein offensichtliches OOM-Ereignis, das das Verhalten erklärt hätte.

Beim Dateisystem:

24 GB total
14 GB used
9.4 GB available
60% used

Der durchschnittliche CPU-I/O-Wait lag bei 0.00%. Gleichzeitig blieb der CPU-Pressure nahe 99 %, der Load Average lag auf der VM mit einer vCPU bei ungefähr 3,5–4, und die Runnable Queue erreichte 11.

Alle Messwerte zeigten damit in dieselbe Richtung: Der Server war CPU-seitig ausgehungert und nicht offensichtlich durch RAM oder Storage blockiert.

Der Widerspruch zu AVAs eigener Formulierung

Genau das finde ich an diesem Fall am interessantesten.

AVA sagt “Guaranteed resources — no sharing”. Die Performance soll nicht von anderen Kunden beeinflusst werden. In den Linux-VPS-Unterlagen heißt es, ein anderer Tenant könne keinen Steal Time verursachen; an anderer Stelle soll CPU-Steal auf Hypervisor-Ebene eliminiert sein.

Mein AVA-VPS zeigte dagegen:

Average CPU steal: 32.73%

Aus der VM heraus kann ich nicht beweisen, warum das passiert ist. Ich kann weder absichtliches Overselling nachweisen noch einen bestimmten Nachbar-Workload identifizieren oder AVAs hostseitige CPU-Konfiguration rekonstruieren.

Ich behaupte auch nicht, dass sich jeder VPS von AVA Hosting so verhält. Ich habe einen VPS getestet.

Aber ich kann sagen, dass sich das gemessene Verhalten nur schwer mit diesen konkreten Aussagen zur CPU-Isolation vereinbaren lässt. Mehr muss dieser Artikel nicht behaupten.

Warum ich nicht aufgerüstet habe

Die offensichtliche Reaktion wäre gewesen, mehr vCPUs zu kaufen.

Hätte der VPS praktisch keinen Steal gezeigt und meine Anwendung einfach einen ganzen Core ausgelastet, wäre ein Upgrade sinnvoll gewesen. Stattdessen entfiel ungefähr ein Drittel der beobachteten CPU-Zeit auf Steal.

Ich wollte nicht für weitere virtuelle CPUs bezahlen, bevor ich verstanden hatte, warum bereits ein so großer Teil der Ausführungszeit der ersten vCPU als nicht verfügbar gemeldet wurde. Deshalb kündigte ich den VPS und verlangte eine Rückerstattung.

AVA hat den gesamten Betrag schnell erstattet

Dieser Teil der Erfahrung war gut.

AVA Hosting erstattete mir den vollständigen Betrag. Die Rückzahlung wurde schnell bearbeitet, und es gab keine tagelange Diskussion über meine CPU-Messungen. Ich erklärte das Problem, verlangte mein Geld zurück, und AVA zahlte es zurück.

Das schätze ich.

Aus meiner Erfahrung ergeben sich deshalb zwei getrennte Aussagen: Der VPS, den ich erhalten hatte, hatte ein ernstes Problem mit der CPU-Verfügbarkeit, und AVA hat meine Rückerstattung korrekt abgewickelt. Beides ist wahr.

Was ich daraus mitgenommen habe

Ich bewerte einen VPS nicht mehr nur anhand von Angaben wie 1 vCPU / 2 GB RAM / NVMe / KVM. Diese Zahlen sagen mir, was provisioniert wurde. Sie sagen mir nicht, wie vorhersehbar die CPU unter realer Last verfügbar sein wird.

Auf einer neuen VM prüfe ich heute sehr früh:

mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60

Die wichtigste Erkenntnis aus meiner Erfahrung mit AVA Hosting war nicht, dass eine vCPU grundsätzlich zu wenig ist. Sondern dass laufende Prozesse, freier RAM und eine unauffällige Platte ein ganz anderes Problem verdecken können.

In meinem Fall machte Linux dieses Problem ungewöhnlich deutlich:

CPU steal:    32.73%
CPU idle:      0.00%
CPU pressure: ~99%

AVA Hosting bewirbt CPU-Ressourcen ohne Sharing und sagt, dass Steal durch benachbarte Workloads nicht auftreten sollte. Mein VPS meldete etwas anderes.

Ich kündigte ihn. AVA erstattete mein Geld vollständig, schnell und ohne Streit.

Damit war dieser Debugging-Tag beendet.