While you might think this should not be a problem, the OOM Killer kills processes that the server has deemed non-essential, not the user. For example, the two applications the OOM Killer usually kills first are Apache® and MySQL® because they use a large amount of memory.
You can use the OOM Killer logs both to identify which hosts in your system have run out of memory and to get detailed information on how much memory different processes were using at the time of the error. You can find an annotated example in the git commit that added this logging information to the Linux kernel.
To verify that the process has been killed, run the pidof command and you will not be able to view the PID. In the above example, the number 9 is the signal number for the SIGKILL signal.
If you want to enable OOM-Killer runtime, then use sysctl command to enable that. The other way to enable or disable is to write the panic_on_oom variable, you can always check the value in /proc. When you set the value to 0 that means the kernel will not panic when out of memory error occurred.
Try this out:
grep -i 'killed process' /var/log/messages
Try this so you don't need to worry about where your logs are:
dmesg -T | egrep -i 'killed process'
-T, --ctime
- Print human-readable timestamps.
Now dstat provides the feature to find out in your running system which process is candidate for getting killed by oom mechanism
dstat --top-oom
--out-of-memory---
kill score
java 77
java 77
java 77
and as per man page
--top-oom
show process that will be killed by OOM the first
Try this out:
grep "Killed process" /var/log/syslog
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With