Hat ein Container ein CPU-Limit und verbraucht er sein Kontingent innerhalb der festen Periode (meist 100 ms), wird er für den Rest der Periode zwangsweise angehalten (Throttling).
Warum CPU-Limit (limit) für den Spielserver-Container, etwa in Kubernetes → Folge Bei einer Häufung von Tick-Berechnungen ist das Kontingent aufgebraucht, Stillstand von einigen Dutzend ms bis zur nächsten Periode → Auf dem Bildschirm Durchschnittliche CPU niedrig, aber der Tick schlägt periodisch aus: Ruckeln und Zeitlupe
Zahl der Worker-Threads an das CPU-Limit anpassen (damit die Runtime nicht so viele Threads erzeugt, wie der ganze Host Kerne hat).
Aufgaben Infrastrukturteam
CPU-Limit großzügig bemessen oder weglassen und dedizierte Kerne zuweisen, Zahl der Throttling-Ereignisse (nr_throttled) überwachen.
Größenordnungen
Arbeiten auf einem Server mit einem Limit von 2 Kernen 8 Threads gleichzeitig, ist das Kontingent der 100-ms-Periode nach 25 ms verbraucht, und es folgen 75 ms Stillstand.
Im Graphen
Steigt mit Spielerzahl und Last · Throttling-Ereignisse (nr_throttled), Server-Tick-Zeit
Wo nachsehen
Zuwachs von nr_throttled und throttled_usec (cgroup v1: nr_throttled und throttled_time) in cpu.stat der Container-cgroup zusammen mit der Server-Tick-Zeit prüfen
Spricht dafür
Durchschnittliche CPU-Auslastung liegt unter dem Limit, trotzdem steigen nr_throttled und throttled_usec ständig, zeitgleich mit den Tick-Spitzen
Spricht dagegen
nr_throttled steigt nicht: diese Ursache scheidet aus. Gerät die VM selbst ins Hintertreffen: „CPU-Steal (virtuelle Maschine)“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
CFS Bandwidth ControlLinux kernel Ist das pro Periode zugeteilte Kontingent aufgebraucht, halten die Threads bis zur nächsten Periode an (Throttling), Standardperiode 100 ms, Statistik nr_throttled
Control Group v2Linux kernel cpu.max hat das Format „$MAX $PERIOD“ (Kontingent, Periode), Standardwert „max 100000“ (Periode 100 ms)