Nähern sich die lebenden Daten der Heap-Grenze, findet jede GC kaum noch etwas zum Freigeben, und die GC läuft ununterbrochen immer wieder.
Warum Lebende Daten erreichen durch Event-Andrang oder ein Leck fast die Heap-Grenze → Folge GC gibt nur wenig frei, sofort folgt die nächste Full GC, der Großteil der CPU-Zeit geht an die GC → Auf dem Bildschirm Ganzer Server wechselt einige Minuten lang zwischen Zeitlupe und Freeze, bis der Prozess wegen Speichermangels beendet wird
Heap deutlich größer als die lebenden Daten zur Spitzenzeit wählen (meist mindestens das 2-Fache), lange referenzierte Daten und Lecks reduzieren.
Aufgaben Infrastrukturteam
Alarm auf den GC-Zeitanteil einrichten, früh neu starten, ohne auf Erholung zu warten, Instanzen mit genug Arbeitsspeicher wählen, damit der Heap wachsen kann.
Größenordnungen
Beansprucht die GC mehr als 10 % der Laufzeit, gilt das meist als Warnsignal. Einige GCs in Java melden einen Out-of-Memory-Fehler, wenn sie 98 % der Zeit mit GC verbringen und trotzdem kaum etwas freigeben.
Im Graphen
Plateau am Limit · Heap nach der GC, GC-Zeitanteil
Wo nachsehen
Prüfen, wie nahe der direkt nach der GC verbleibende Heap am maximalen Heap liegt und welcher Zeitanteil auf die GC entfällt. Java: „nach der GC(Heap-Größe)“ in den -Xlog:gc-Zeilen und Häufigkeit der Zeilen mit Pause Full, .NET: dotnet-counters (bis .NET 8 % Time in GC since last GC, ab .NET 9 Zuwachs von dotnet.gc.pause.time), Go: Abstand zwischen den Zeilen von GODEBUG=gctrace=1
Spricht dafür
Heap bleibt auch direkt nach der GC nahe am Maximum, Full GCs laufen direkt hintereinander, GC-Zeitanteil steigt weit über den Normalwert (meist über 10 %). Währenddessen werden die Ticks des ganzen Servers langsamer
Spricht dagegen
Nach der GC genug Heap frei, nur die Pausen sind lang: GC-Verfahren oder -Einstellungen (mem-gc)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
The Parallel CollectorOracle Parallel GC wirft OutOfMemoryError, wenn sie über 98 % der Gesamtzeit mit GC verbringt und weniger als 2 % des Heaps freigibt
Garbage-First Garbage Collector TuningOracle G1 bemisst den Heap standardmäßig (GCTimeRatio=12) so, dass die GC-Zeit bei höchstens etwa 8 % der Gesamtzeit liegt, Full GCs wegen zu hoher Heap-Belegung erscheinen im Log als Pause Full (G1 Compaction Pause)
A Guide to the Go Garbage CollectorGo Mit dem Standardwert GOGC=100 liegt der Ziel-Heap bei etwa dem 2-Fachen des lebenden Heaps, nahe am Speicherlimit läuft die GC ununterbrochen (Thrashing), GODEBUG=gctrace=1 gibt einen GC-Trace aus
Garbage Collector ImplementationOracle -Xlog:gc-Zeilen zeigen GC-Art (Pause Young, Pause Full), „Belegung vor der GC->Belegung nach der GC(Heap-Größe)“ und Pausendauer