Nicht freigegebener Speicher sammelt sich nach und nach an und führt Tage später zu GC-Stürmen, Swapping oder zum erzwungenen Beenden des Prozesses.
Warum Daten ausgeloggter Charaktere und Event-Handler werden nicht freigegeben → Folge Freier Speicher nimmt über mehrere Tage ab → Auf dem Bildschirm Direkt nach der Wartung unauffällig, mit jedem Tag mehr Lag, am Ende fällt der Server aus
Trend des Speicherverbrauchs pro Prozess überwachen und Alarme dafür einrichten.
Im Graphen
Langsamer Anstieg · Prozessspeicher (RSS), Heap nach der GC
Wo nachsehen
Speicher des Spielserverprozesses (RSS aus pidstat -r) über mehrere Tage verfolgen, bei Servern mit GC den direkt nach der GC verbleibenden Heap. Java: der Wert nach der GC aus der Vorher-/Nachher-Belegung in den -Xlog:gc-Zeilen, .NET: Heap-Größe nach der GC in dotnet-counters (ab .NET 9 dotnet.gc.last_collection.heap.size, bis 8 GC Heap Size)
Spricht dafür
Der direkt nach der GC verbleibende Heap (Grundlinie) steigt nach dem Neustart jeden Tag und sinkt auch in den ruhigen frühen Morgenstunden nicht
Spricht dagegen
Heap-Grundlinie flach, nur RSS steigt: Fragmentierung (mem-fragment) oder nativer Speicher. Steigt und fällt mit der Spielerzahl: normaler Verbrauch
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Wird der Server bei der regelmäßigen Wartung jede Woche neu gestartet, bleibt ein Leck verdeckt und lange unentdeckt. Oft tritt es plötzlich zutage, wenn eine Wartung einmal verschoben wird oder ein Event mehr Spieler bringt.
Quellen
Troubleshoot Memory LeaksOracle Wird die Ausführung allmählich langsamer, liegt ein Leck nahe, am Ende geht der Speicher aus und das Programm bricht ab. Wichtigste Grundlage der Leckanalyse ist ein Heap-Dump
Debug a memory leak in .NET.NET Auch mit GC entsteht ein Leck, wenn nicht mehr benötigte Objekte weiter referenziert werden, Folge sind Leistungseinbußen und OutOfMemoryException. Speichertrend prüfen und Dumps analysieren