Returned to the company this morning, found that a server game process hangs, the first thought is that the cloud server host downtime caused by the restart (because previously encountered two times)
So immediately log on to the server to view, first look at the process log to determine the process was killed at the point of time, and then view the kernel log/var/log/message found as follows
Determine that the memory is not enough to cause the system to trigger the Oom-killer mechanism, the process to kill off.
Below you share the following oom-killer mechanism:
Collected at the following address:
17350711
26271293
Linux allows programs to request more memory than the system has available memory, this feature is called Overcommit.
This is done for optimal system consideration, because not all applications use memory immediately, and when you use it, the system may have reclaimed some resources.
Unfortunately, when you use this overcommit to your memory, the system has no resources, and OOM killer jumps out.
To protect important processes from being oom-killer, we can: ECHO-17 >/PROC/<PID>/OOM_ADJ,-17 Disables Oom
we can also take the whole system oom is disabled:
Sysctl-w vm.panic_on_oom=1 (default = 0, open)
Sysctl-p
Parameter/proc/sys/vm/overcommit_memory to control the process's coping strategies for excessive memory usage
When the overcommit_memory=0 allows the process to use slightly excessive memory, but is not allowed for large overload requests (default)
When Overcommit_memory=1 always allows the process to Overcommit
When overcommit_memory=2 forever forbid overcommit
This selection strategy has been evolving over Linux. As a user, we can make decisions by setting some values to influence oom killer. Linux under each process has an oom weight, in the/proc/<pid>/oom_adj, the value is 17 to +15, the higher the value, the more easily be killed.
The final Oom killer is determined by the value of/proc/<pid>/oom_score to determine which process was killed. This value is the memory consumption of the system synthesis process, the CPU time (Utime + stime), the time of survival (Uptime-start times), and the Oom_adj computed, the more memory consumed, the higher the survival time is lower.
In short, the overall strategy is to lose the least amount of work, freeing up maximum memory without hurting innocent processes that use a lot of memory, and killing as few processes as possible.
Linux Oom-killer mechanism (out of memory)