Why does my game server run out of memory?

Almost always a memory leak that accumulates over the server's long uptime, most commonly per-match or per-player data that isn't fully freed when matches end or players leave, so a little memory leaks each session and, over thousands of sessions, climbs until exhausted. A freshly-started server is fine; one up for hours/days under load runs out, the signature of per-session accumulation.

How do I find a memory leak on my game server?

Profile the server's memory over uptime and correlate OOM crashes with uptime and session count: steadily climbing memory (and crashes after long uptime / many sessions) confirms per-session accumulation. Then cycle the server through many matches and players and watch what isn't released after sessions end, usually per-match state or per-player objects lingering due to retained references.

How do I stop per-match memory from leaking on my server?

Audit the end-of-match and player-disconnect paths to ensure complete cleanup: when a match ends, release all its memory (state, spawned objects, buffers, and any references holding them alive); when a player leaves, release all their data and remove references to them. The common leak is per-session data almost-but-not-fully freed due to a lingering reference. Verify by confirming memory returns to baseline after each session ends rather than climbing over uptime.

How to Fix a Game Server That Runs Out of Memory

Quick answer: A game server that runs out of memory almost always has a memory leak that accumulates over the server's long uptime, commonly per-match or per-player data that isn't fully freed when matches end or players leave, so memory creeps up with every session until exhausted. Profile what grows over the server's uptime, ensure each ended session and departed player is completely cleaned up, and bound any data that accumulates, so the server's memory stays stable indefinitely.

Game servers run for a long time, hours or days, handling many matches and players in sequence, which makes them especially vulnerable to memory leaks: even a tiny leak per match adds up over thousands of matches until the server runs out of memory and crashes (dropping everyone). Server OOM is usually an accumulation problem tied to the server's long uptime and high session turnover.

Why Servers Run Out of Memory

Unlike a client (which restarts frequently), a server runs continuously for a long time, processing a stream of matches and players. This long uptime means any memory that isn't freed accumulates relentlessly. The classic cause: per-match or per-player data not cleaned up, when a match ends or a player disconnects, the memory associated with it (game state, player objects, buffers, event subscriptions) isn't fully released, so a little leaks each time, and over thousands of matches/players the server's memory climbs until it's exhausted.

Other causes: growing data structures (logs, caches, histories that accumulate over uptime), and leaks in long-running systems. The signature is server memory climbing steadily over uptime and OOM crashes correlated with how long the server has been running (and how many sessions it's processed). A freshly-started server is fine; one that's been up for hours/days under load runs out.

How to Diagnose It

Profile the server's memory over uptime, does it climb steadily as it processes matches/players, or stay flat? A rising trend over uptime confirms a leak. Correlate OOM crashes with uptime and session count, crashes that happen after long uptime / many processed sessions point at per-session accumulation. Then find what's not being freed: cycle the server through many matches/players and watch what accumulates (often per-match state or per-player objects that survive after the session ends).

Bugnet captures crashes with context and the build version, so server OOM crashes cluster and, correlated with uptime/session count, confirm an accumulation/leak pattern. For server fleets, aggregating these shows it's systemic. Server-side memory monitoring over uptime is the key diagnostic, the leak reveals itself as memory that grows with sessions processed rather than staying bounded.

How to Fix It

Ensure complete cleanup of sessions and players. When a match ends, fully release all its memory, game state, spawned objects, buffers, and any references holding them alive. When a player leaves, release all their associated data and remove references to them. The most common server leak is per-session data that's almost-but-not-fully cleaned up, references lingering somewhere that prevent the session's memory from being freed, so audit the end-of-match and player-disconnect paths to ensure nothing is retained. Bound any growing structures (cap logs/histories, evict caches).

Verify by profiling: cycle the server through many matches/players and confirm memory returns to baseline after each session ends (stays flat over uptime) rather than climbing, that's the definitive test that the leak is fixed. As a safety net while fixing (and against unknown leaks), monitoring with automatic restart can prevent OOM crashes from dropping players, but the real fix is stable memory. After fixing, the server should run indefinitely under load without its memory growing. Because a server OOM crash drops everyone on it, eliminating server leaks is critical to multiplayer stability.

Servers run for days, so a tiny per-match leak compounds into OOM. Ensure ended matches and departed players are fully freed, and verify memory returns to baseline each session.