When memory runs out, Linux picks the process using the most memory and kills it. Usually that’s the game server.
Why Memory runs out from a leak or a surge in usage, or the container hits its memory limit → Effect The kernel kills the game server process → On screen Everyone on that server disconnects at once, and recent progress may be rolled back
Primary owner Game team (Server development) · Also Infra team (Server infrastructure)
Game team action items
Fix leaks, set a memory usage ceiling with a procedure that saves and shuts down cleanly as usage approaches it.
Infra team action items
Set memory alerts, size the container memory limit to actual usage, adjust which process gets killed first (oom_score_adj).
Ballpark numbers
The kernel log (dmesg) records “Out of memory: Killed process”, and Kubernetes shows OOMKilled. Windows has no OOM killer; there the server usually dies with an error when a memory allocation fails.
On the graph
Mass disconnect · Connection count, memory usage
Where to look
“Out of memory: Killed process” entries in dmesg, OOMKilled in the pod status on Kubernetes, or an increase in oom_kill in memory.events on cgroup v2, lined up with the time connections dropped
Confirmed if
At the moment connections dropped all at once, a record shows the game server process being killed, and memory usage had been climbing to the limit right before
Ruled out if
No OOM record but the process died: check the crash log and core dump (see “Server crash”)
Check with
Infra tools (no game code needed)
Sources
mm/oom_kill.c (Linux v6.12)Linux kernel The process using the most memory gets the highest score (oom_score_adj factored in); the kernel logs “Out of memory: Killed process …” when it kills
Pushing the Limits of Windows: Virtual MemoryMicrosoft On Windows, once the commit limit is reached, allocations that commit memory fail, which can lead to app errors or system failures
Control Group v2Linux kernel oom_kill in memory.events: number of processes in this cgroup killed by the OOM killer