Memory that is never freed piles up little by little and, days later, leads to GC storms, swapping, or the process getting killed.
Why Data for logged-out characters and event handlers is never freed → Effect Free memory shrinks over several days → On screen Fine right after maintenance, laggier every day, and eventually the server goes down
Primary owner Game team (Server development) · Also Infra team (Server infrastructure)
Game team action items
Analyze heap dumps, run long-duration load tests.
Infra team action items
Monitor and alert on per-process memory usage trends.
On the graph
Slow climb · Process memory (RSS), heap after GC
Where to look
Watch the game server process’s memory (RSS from pidstat -r) over several days; on servers with GC, watch the heap left right after GC. Java: the after-GC value in the before/after usage of -Xlog:gc lines. .NET: the post-GC heap size in dotnet-counters (dotnet.gc.last_collection.heap.size on .NET 9 and later, GC Heap Size on 8 and earlier)
Confirmed if
The heap left right after GC (the baseline) climbs every day after a restart and doesn’t come down even in the quiet early-morning hours
Ruled out if
Heap baseline flat while only RSS climbs: fragmentation (mem-fragment) or native memory. Rises and falls with player count: normal usage
Check with
Infra tools (no game code needed)
Learn more
Weekly restarts during scheduled maintenance hide a leak, so it can go unnoticed for a long time. It often shows up suddenly when maintenance is postponed once or an event brings in more players.
Sources
Troubleshoot Memory LeaksOracle Suspect a leak when execution gets gradually slower; memory eventually runs out and the program terminates abnormally. The key data for leak analysis is a heap dump
Debug a memory leak in .NET.NET Even with GC, holding references to objects no longer needed is a leak, leading to performance degradation and OutOfMemoryException. Check memory trends and analyze dumps