Skip to main content

OOM Killer

What Is The OOM Killer?

The OOM Killer or Out Of Memory Killer is a process that the linux kernel employs when the system is critically low on memory. This situation occurs because the linux kernel has over allocated memory to its processes. When a process starts it requests a block of memory from the kernel. This initial request is usually a large request that the process will not immediately or indeed ever use all of. The kernel, aware of this tendency for processes to request redundant memory, over allocates the system memory. This means that when the system has, for example, 2GB of RAM the kernel may allocate 2.5GB to processes. This maximises the use of system memory by ensuring that the memory that is allocated to processes is being actively used.

Normally, this situation does not cause a problem. However, if enough processes begin to use all of their requested memory blocks then there will not be enough physical memory to support them all. This means that the running processes require more memory than is physically available. This situation is critical and must be resolved immediately.

The solution that the linux kernel employs is to invoke the OOM Killer to review all running processes and kill one or more of them in order to free up system memory and keep the system running.

How Does It Select A Process To Kill?

The OOM Killer works by reviewing all running processes and assigning them a badness score. The process that has the highest score is the one that is killed. The OOM Killer assigns a badness score based on a number of criteria. The principle of which are as follows are as follows:

  • The process and its all of its child processes are using a lot of memory
  • The minimum number of processes are killed (ideally one) in order to free up enough memory to resolve the situation
  • Root, kernel and important system processes are given much lower scores

So Why Is Apache / MySQL Always Killed?

The above listed criteria mean that when selecting a process to kill the OOM Killer will choose a process using lots of memory and has lots of child processes and which are not system processes. An application such as apache, mysql, ftp server or a mail server will make an good candidate. However, as this situation usually occurs on a busy web server Apache or MySQL will be the largest in-memory, non-system processes and consequently get killed.

It must be remembered that although the webserver or db server are very important to you when the kernel calls the OOM Killer the situation is critical. If memory is not freed by killing a process the server will crash very shortly afterwards. Continuing normal operations at this juncture is impossible.

How To Find Out If The OOM Killer Was Running

The easiest way to find if the OOM Killer was the reason that a website went offline is to check the system log. Whenever the OOM Killer is invoked it will write a great deal of information to the system log including which process was killed and why. If the following command is run:

dmesg | egrep -i “killed process”

The output will look like the following

host kernel: Out of Memory: Killed process 2592 (mysql).

In this instance the process that was killed was mysql which has the PID (Process Identification Number) of 2592.

How To Avoid The OOM Killer

The OOM Killer will only get invoked when the system is critically low on memory. Consequently the solution to avoiding it is to either reduce the memory requirements of the server or increase the available memory.

Upgrade The Server

This is the fastest and easiest option as it will require no work re-configuring the server. The sales team will be happy to discuss your requirements and make a recommendation. They can be contacted at:

Sales@Memset.com

0800 634 9270

Reduce Memory Usage

The first step that should be taken to reduce memory usage to stop any processes running that are not needed. For example if the server is not shared and FTP is only occasionally used then this process can be initiated prior to uploading and terminated afterwards.

WHM / cPanel servers generally have a lot of processes running which consume a lot of memory. Some of these can be stopped if they are not being used. This is done via the “Service Manager” page in WHM. The docs for this page can be read here:

http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/ServiceMgr

The second way to reduce memory usage is use an alternative application or configuration that has a lower memory footprint. An obvious candidate for this is Apache. Apache is a very capable webserver but is not know for is parsimonious use of system resources. There are very many alternative web servers but two well know web servers which show a decreased memory usage compared to apache are nginx and lighttpd.

Swapping to nginx from apache will make a large difference to memory usage but only on a busy webserver.

Alternatively, using a reverse proxy to serve static content will reduce memory usage and increase page load times by serving content directly from ram before apache has to start a thread to serve it. Varnish cache is an excellent reverse proxy. Further information can be found on their site:

https://www.varnish-cache.org/

Furthermore, the serving of static content, e.g. images, can be offloaded to the Memset CDN. This will reduce the memory and cpu overhead of serving the site because the browser will request the images directly from the Memset CDN server. More about this service can be read here:

http://www.memset.com/cloud/storage/

WHM / cPanel server do not have very much choice in which application to use as often the only availible option is the one supplied by WHM. However, in the case of the FTP server and mail server there are two choices for each one. One choice has a lower memory foot print and should be switched to if memory constraints are an issue.

Choosing alternative applications or tweaking configuration will only produce limited results. Increasing the available RAM to an amount sufficient to support the needed processes is always the best solution.

Last updated 4 May 2017, 06:41 GMT