Oom

oom_killer By default, when there is no memory available and memory is used, the Linux kernel's oom_killer (out of memory killer) scans the program that has the most memory (may have multiple) and ends them. Drop it. This kind of scanning is actually quite expensive. You can choose to let oom_killer not scan out the processes with the most memory, but solve those processes that apply for memory: sysctl -w vm.oom_kill_allocating_task = 1 With this setting, oom_killer will not spend Time to find the process that occupies the most memory to kill, large memory programs have a chance to survive. But at the moment when the memory runs out, whoever applies for or uses a blank memory will be tragedy, and it may be that several processes are killed together, full of unpredictability (for example, Xorg is killed, so Many programs are hanged together, and the mysqld in the background will be inconvenient if it is killed. It also does not prevent pdflush from flashing at the last minute. In short, oom_killer is very uncoordinated, it is best not to let it play. At this point, openSolaris seems to do a better job. From the outside, when the memory is not enough, the system will not actively kill the running program, but refuse to run the new program, and if the running program is running, Applying for memory will be suspended until there is memory available to it. Overcommit So why can't the system detect that the memory is running out before, malloc is likely to return NULL? In the current operating system
, it is allowed to apply for memory excessively. If you only apply for memory and do not actually use it, you can apply for much more space than the actual memory (for example, use malloc to apply for memory, while(1) malloc (x); such a program can run for a long time), only once started to use (such as filling with memset), it is counted into the real memory usage, then if the memory is really not enough, then oom_killer will play. Currently Linux provides some options to adjust this memory strategy :-)

By default, vm.overcommit_memory = 0, this time you can apply for more memory, but still at a certain time The application failed.

There is more lenient, if vm.overcommit_memory = 1, all malloc will unconditionally succeed quite a terrible world.

The last option is this: sysctl -w vm.overcommit_memory = 2 At this time, there is a strict limit on the total amount of memory requested, malloc will return NULL when the limit is exceeded, the application can handle this properly In this case, oom_killer will never come out again, pdflush will not let the hard disk turn the system does not respond, if a program can not properly handle this situation, it will immediately hang, clean and neat.

But this also has some disadvantages. At this time, the parameter vm.overcommit_ratio will also work. The default is 50, which means that it can only be allocated to 50% of the actual physical memory. If there is no exchange area, the overcommit_ratio setting is small and it will be very tragic, almost nothing can be done. Then set it to 100, things are very harmonious? Not so simple, the limit here is the limit on the total number of applications for memory. If the application is not actually used, it is counted in the total. In this case, the actual memory is not used up, the program is likely to not be able to apply for memory, and some memory is wasted. Although overcommit_ratio can be set to a number greater than 100, it is a tricky problem to set it. If the setting is large, there is no limit. When the memory is used up, the hard disk will be mad, the system will lose response for a while, oom_killer has May be on the scene, the settings are small, it is possible that hundreds of megabytes of memory is wasted. Check the memory information can be seen:

% cat /proc/meminfo

MemTotal: 2064616 kB

MemFree: 1556672 kB

….

CommitLimit: 2064616 kB

Committed_AS: 769068 kB

….

where Committed_AS is the sum of the memory requested by the program and cannot exceed CommitLimit.

It is obvious that Committed_AS+MemFree is larger than MemTotal, and it seems appropriate to set CommitLimit to Committed_AS+MemFree.