Der Spielcode ist unverändert, doch nach einem Update von Server-OS, Kernel, Treibern oder Firmware wird es langsamer. Updates können Standardwerte, den Scheduler, die Schutzmaßnahmen gegen CPU-Sicherheitslücken (Mitigations) und das Verhalten von Treibern ändern.
Warum Kernel, Treiber oder Firmware ändern sich durch regelmäßige Sicherheitspatches oder ein neues Server-Image → Folge Geänderte Standardwerte oder Scheduler oder neu aktivierte Mitigations: Dieselbe Arbeit kostet mehr CPU-Zeit, und Threads bekommen in anderer Reihenfolge CPU-Zeit → Auf dem Bildschirm Ein bisher problemloser Server ist ab dem Update-Tag dauerhaft etwas langsamer: Input-Lag, bei großem Andrang Ruckeln und Zeitlupe
Updates zuerst auf einigen Servern einspielen, Tick-Zeit, Latenz und CPU-Auslastung mit der Vorversion vergleichen und erst dann ausweiten, nicht am selben Tag wie Spiel-Patches ausrollen, Kernel-, Treiber- und Firmware-Versionen sowie wichtige sysctl-Werte vor und nach dem Update festhalten, bei Problemen zum Vergleich mit dem vorherigen Kernel booten, über das Abschalten der Mitigations (mitigations=off) erst nach Abwägung des Sicherheitsrisikos entscheiden.
Größenordnungen
Mit der Kernelversion ändert sich auch das Standardverhalten. Linux begann zum Beispiel mit 6.6, den Scheduler von CFS auf EEVDF umzustellen, und der Standardwert für das Limit der Verbindungswarteschlange (somaxconn) stieg mit 5.4 von 128 auf 4096. Mitigations gegen CPU-Sicherheitslücken verursachen zusätzliche Arbeit, etwa das Leeren CPU-interner Puffer beim Rücksprung vom Kernel ins Programm (nach jedem Systemaufruf) sowie bei Kontextwechseln und VM-Wechseln. Netzwerkserver, die für jedes Paket einen Systemaufruf machen, trifft das besonders. Manche Lücken lassen sich nur vollständig schließen, wenn SMT (ein Kern arbeitet wie zwei Threads) abgeschaltet wird, und ohne SMT sinkt die Leistung je nach Workload deutlich. Der Kernelparameter mitigations=off schaltet alle diese Mitigations ab und holt die Leistung zurück, lässt die Lücken aber offen.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · Server-Tick-Zeit, CPU-Auslastung, Latenz bei gleicher Last
Wo nachsehen
Update-Verlauf des Paketmanagers und Neustartzeitpunkte, Kernelversion aus uname -r und NIC-Treiberinformationen aus ethtool -i mit dem Zeitpunkt des Latenzanstiegs abgleichen. Aktualisierte und nicht aktualisierte Server bei gleicher Last mit mpstat und pidstat vergleichen, ebenso den Zustand der Mitigations unter /sys/devices/system/cpu/vulnerabilities/
Spricht dafür
Latenz und CPU-Auslastung steigen ab dem Neustart nach dem Update um eine Stufe und bleiben dort, bei gleicher Last sind nur die aktualisierten Server höher. Mit dem vorherigen Kernel oder Treiber gebootet, normalisieren sich die Werte
Spricht dagegen
Aktualisierte und nicht aktualisierte Server bei gleicher Last gleich langsam: diese Ursache scheidet aus. Wurde am selben Tag auch ein Spiel-Patch ausgerollt und haben sich Zahl oder Größe der Pakete pro Spieler geändert: „Patch verändert das Traffic-Muster“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Den Zustand der Mitigations zeigen die Dateien unter /sys/devices/system/cpu/vulnerabilities/. Der Standard (mitigations=auto) schützt bei eingeschaltetem SMT. Mit auto,nosmt wird SMT auf anfälligen CPUs abgeschaltet, und nach dem Kernel-Update kann sich die Zahl der logischen Kerne halbieren. Wird das OS am selben Tag wie ein Spiel-Patch aktualisiert, lässt sich die Ursache schwer eingrenzen. Beides deshalb getrennt ausrollen.
Quellen
The kernel’s command-line parametersLinux kernel mitigations=: off schaltet alle Mitigations gegen CPU-Sicherheitslücken ab und erhöht die Leistung, lässt die Lücken aber offen, Standard auto schützt bei eingeschaltetem SMT, auto,nosmt schaltet SMT bei Bedarf ab
MDS - Microarchitectural Data SamplingLinux kernel Mitigations leeren CPU-Puffer beim Rücksprung vom Kernel in den User Space und beim Eintritt in eine VM, Zustand von Lücken und Mitigations in den Dateien unter /sys/devices/system/cpu/vulnerabilities/, bei vielen CPUs ist für vollständigen Schutz das Abschalten von SMT nötig, was je nach Workload die Leistung stark beeinträchtigt
Spectre Side ChannelsLinux kernel Als Mitigation werden bei Kontextwechseln und VM-Wechseln die Puffer der Sprungvorhersage geleert, starke Mitigations erzeugen Overhead für alle Programme
EEVDF SchedulerLinux kernel Linux begann mit 6.6, von CFS auf den Scheduler EEVDF umzustellen