Game-Lag-Whitepaper › L11 Datenträger

Lazy Loading auf dem Server Lazy loading on the server

Ursachen-ID dk-lazy-load · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Liest der Server Dungeon- oder Kartendaten erst bei der ersten Anfrage vom Datenträger, stehen alle still, bis dieser Tick fertig ist.

Warum Jemand betritt als Erster einen Dungeon oder ein Gebiet → Folge Der Server liest die Daten im Game-Thread vom Datenträger → Auf dem Bildschirm Alle auf diesem Server stehen kurz still

Symptome

Freeze

Faktoren

Stillstand

Wer ist betroffen

Bestimmter Ort oder Kanal, Ganzer Server

Wann

Beim Bewegen oder Zonenwechsel

Zuständigkeit

Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

Aufgaben Entwicklungsteam

Daten beim Serverstart vorladen, asynchron laden.

Aufgaben Infrastrukturteam

Bei Servern, die gerade aus einem Snapshot erstellt wurden, den Datenträger vor der Inbetriebnahme vorwärmen (alle Blöcke einmal lesen) oder Fast Snapshot Restore nutzen.

Im Graphen

Vereinzelte Spitzen ohne Muster · Server-Tick-Zeit, Disk-Lesezugriffe

Wo nachsehen

Zeitpunkte des Stillstands mit den Einträgen zum ersten Betreten von Dungeons oder Gebieten im Spielserver-Log abgleichen, für diesen Moment die Disk-Lesezugriffe des Spielservers (kB_rd/s aus pidstat -d) und mit perf trace --duration langsame read- und open-Aufrufe prüfen. Bei neu gestarteten Cloud-Servern VolumeAvgReadLatency von EBS mit älteren Servern vergleichen

Spricht dafür

Stillstand nur beim ersten Betreten, beim zweiten Betreten desselben Orts nicht. Während des Stillstands wartet der Game-Thread auf das Lesen einer Datei

Spricht dagegen

Gleicher Stillstand auch in bereits geladenen Gebieten: andere Ursache wie überschrittenes Tick-Budget oder GC

Prüfmittel

Logs oder Metriken aus Spielserver bzw. Client nötig

Mehr dazu

In der Cloud holt ein Server, der gerade aus einem Snapshot (Kopie eines Datenträgers) erstellt wurde, jeden Block beim ersten Lesen aus einem entfernten Storage und ist dadurch deutlich langsamer als sonst. Dauert der erste Eintritt nur auf Servern, die per Autoscaling neu gestartet wurden, auffällig lange, liegt dieser Verdacht nahe.

Quellen

1. Initialize Amazon EBS volumes AWS
   Aus einem Snapshot erstellte Volumes haben höhere Latenz und geringere Leistung, solange Blöcke aus S3 geholt werden; vorab mit dd oder fio alle Blöcke lesen und so initialisieren
2. Amazon EBS fast snapshot restore AWS
   Fast Snapshot Restore liefert Volumes, die schon beim Erstellen initialisiert sind, und beseitigt so die Latenz beim ersten Zugriff
3. pidstat(1) — Linux manual page sysstat
   -d: kB_rd/s je Prozess (pro Sekunde vom Datenträger gelesene Datenmenge)
4. perf-trace(1) — Linux manual page perf
   --duration zeigt nur Systemaufrufe, die länger als die angegebenen ms dauerten
5. Amazon CloudWatch metrics for Amazon EBS AWS
   VolumeAvgReadLatency: Leselatenz im 1-Minuten-Mittel (Nitro-Instanzen)

Verwandte Ursachen

Gleiche Schicht: L11 Datenträger

• Synchrones Schreiben von Logs
• fsync-Flut
• Aufgebrauchte Burst-Credits beim Cloud-Datenträger
• IOPS-Limit und volle Warteschlange
• Datenträger voll
• Backup-, Komprimierungs- und Scan-Jobs
• Schreiben von Core-Dumps
• Seek-Latenz von HDDs

Ursachen aus anderen Schichten mit demselben Symptom (Freeze)

• Frametime-Spikes L1 Spielprozess auf dem Client
• Garbage Collection auf dem Client L1 Spielprozess auf dem Client
• Synchrones Laden und Shader-Kompilierung im Main-Thread L1 Spielprozess auf dem Client
• Langsamer Datenträger bremst Asset-Streaming L1 Spielprozess auf dem Client
• Prüfungen des Sicherheitsmoduls (Anti-Cheat) L1 Spielprozess auf dem Client
• Wechsel WLAN ↔ LTE/5G L2 Client-OS und Gerät
• Zu wenig Arbeitsspeicher und Swap auf dem Client L2 Client-OS und Gerät
• Zu wenig Grafikspeicher (VRAM) L2 Client-OS und Gerät

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen