My blog Address
What happens when there is not enough memory, the result is very simple, Linux memory used up, unable to request a buffer, the kernel will pick the process to kill it, in general, killing the application of memory program. Frequent disk swap operations often occur with this type of problem, or too many processes are started during concurrent processing.
The reason for the memory exhaustion is simple, the size of the memory you requested exceeds the amount of virtual memory available, note that virtual memory (memory is not unique, swap partition can also provide memory)
Explore Oom (out of memory)
Run the following program first and keep requesting large amounts of memory:
#include <stdio.h>
#include <stdlib.h>
#define MEGABYTE 1024*1024
int main (int argc, char * Argv[])
{
void *myblock = NULL;
int count = 0;
while (1)
{
Myblock = (void *) malloc (megabyte);
if (!myblock) break;
printf ("Currently allocating%d mb\n", ++count);
}
Exit (0);
}
The above program runs for a oom, now runs another program, keeps applying for memory, and fills it up to 1.
#include <stdio.h>
#include <stdlib.h>
#define MEGABYTE 1024*1024
int main (int argc, char * Argv[])
{
void *myblock = NULL;
int count = 0;
while (1)
{
Myblock = (void *) malloc (megabyte);
if (!myblock) break;
memset (myblock,1, megabyte);
printf ("Currently allocating%d mb\n", ++count);
}
Exit (0);
}
Is there anything different, in fact, program 1 can request more memory than program 2. Both programs exit because there is not enough space, but the program 1 exit because of the failure of the malloc, and the program 2 exit is because the kernel called Oom killer killed it.
When the program 2 exits:
Currently Allocatinn 1589 MB
When the program 1 exits:
Currently allocating 274520 MB (64-bit system)
Why program 1 compared to program 2 can allocate so much memory, because Linux uses a deferred page allocation. That is, memory is allocated only when it is really used, and this technique is known as optimistic memory allocation.
You can see this by looking at the/proc/pid/status file. (where Vmdata is the virtual memory consumed)
The first is Program 1:
And then the program 2:
When we request a memory area, the C library determines whether the current preconfigured memory block is large enough, and if not enough, the program will gain memory by extending the heap space.
View file/proc/pid/maps can see the memory blocks in the heap.
When the memory runs out, Oom killer will select the process that needs to be killed according to the policy, and the policy can be configured. The oom_score of each process is dynamic, the larger the more likely to be killed.
You can know the value of the process by looking at/proc/pid/oom_score. Generally, the higher the value of memory consumption, the smaller the value of the earlier run time.
At the same time, some relatively important processes in the system may get higher values, which can be used/proc/pid/oom_adj files. If you set the value inside to an integer, the more likely it is that the process will be killed, and the opposite is set to a negative number, and the chances of surviving. When this value is -17,oom-killer, the process is completely ignored.
Of course, this approach is not easy to implement and manage, there are other ways to write code management Oom-killer.
If the system has logs, the killer log will be saved to
Grep-i kill/var/log/messages*
Depending on this log, you can adjust your policies to ensure that important processes are functioning properly, such as databases and Web services.
The Oom-killer code is located in the MM/OOM_KILL.C
The order of the calls is malloc-> _alloc_pages-> out_of_memory ()-> select_bad_process ()-> badness ()