Entstehen während eines Events massenhaft temporäre Objekte, läuft die GC viel häufiger als sonst.
Warum Item-Drops, Kampflogs und Event-Belohnungen lassen die Zahl temporärer Objekte explodieren → Folge GC läuft um ein Vielfaches häufiger, noch nicht verworfene Objekte wandern in die Old Generation, dadurch kommt auch die Full GC früher → Auf dem Bildschirm Kurzes Stocken in festen Abständen, nur während Events
Objekt-Pools und wiederverwendbare Puffer nutzen, Allokationen mit einem Profiler untersuchen.
Im Graphen
Steigt mit Spielerzahl und Last · Anzahl der GCs, Allokationsrate
Wo nachsehen
GCs pro Minute im GC-Log zählen (Java -Xlog:gc, Go GODEBUG=gctrace=1), bei .NET Allokationsmenge und GC-Anzahl in dotnet-counters prüfen (ab .NET 9 dotnet.gc.heap.total_allocated und dotnet.gc.collections, bis 8 Allocation Rate und Gen 0 GC Count). Mit der Zahl gleichzeitiger Spieler und den Event-Zeiten übereinanderlegen
Spricht dafür
Mit Event-Beginn steigen Allokationsrate und GC-Anzahl steiler als die Spielerzahl, kurze Pausen häufen sich. Nach dem Event wieder normal
Spricht dagegen
GC-Anzahl unverändert, aber einzelne Pausen werden länger: Die lebenden Daten sind gewachsen (mem-gc-thrash, mem-leak)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
Garbage Collector ImplementationOracle Ist die Young Generation voll, folgt eine Minor GC. Ein Teil der überlebenden Objekte wandert in die Old Generation, ist diese voll, wird der gesamte Heap gesammelt (dauert viel länger als eine Minor GC), -Xlog:gc schreibt eine Zeile pro GC
dotnet-counters diagnostic tool.NET Ab .NET 9 Anzeige als dotnet.gc.heap.total_allocated und dotnet.gc.collections, bis .NET 8 als Allocation Rate und Gen 0 GC Count