Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I use the default settings:

vm.overcommit_memory = 0
vm.overcommit_ratio = 50

I can read these values from /proc/meminfo file:

CommitLimit:     2609604 kB
Committed_AS:    1579976 kB

But when I change vm.overcommit_memory from 0 to 2, I'm unable to start the same set of applications that I could start before the change, especially amarok. I had to change vm.overcommit_ratio to 300, so the limit could be increased. Now when I start amarok, /proc/meminfo shows the following:

CommitLimit:     5171884 kB
Committed_AS:    3929668 kB

This machine has only 1GiB of RAM, but amarok works without problems when vm.overcommit_memory is set to 0. But in the case of setting it to 2, amarok needs to allocate over 2GiB of memory. Is it a normal behavior? If so, could anyone explain why, for instance, firefox (which consumes 4-6x more memory than amarok) works in the same way before and after the change?

share|improve this question
up vote 26 down vote accepted

You can find the documentation in man 5 proc (or at

This file contains the kernel virtual memory accounting mode. Values are:

0: heuristic overcommit (this is the default)
1: always overcommit, never check
2: always check, never overcommit

In mode 0, calls of mmap(2) with MAP_NORESERVE are not checked, and the default check is very weak, leading to the risk of get-ting a process "OOM-killed". Under Linux 2.4 any non-zero value implies mode 1. In mode 2 (available since Linux 2.6), the total virtual address space on the system is limited to (SS + RAM*(r/100)), where SS is the size of the swap space, and RAM is the size of the physical memory, and r is the contents of the file /proc/sys/vm/overcommit_ratio.

The simple answer is that setting overcommit to 1, will make it when a program calls something like malloc() to allocate a chunk of memory (man 3 malloc), it always succeeds regardless if the system knows it will have all the memory asked for.

The underlying concept to understand is the idea of virtual memory. Programs see a virtual address space that may, or may not, be mapped to actual physical memory. By disabling overcommit checking, you tell the OS to just assume that there is always enough physical memory to back up the virtual space.

share|improve this answer
But shouldn't the value of Committed_AS be the same in both cases? – Mikhail Morfikov Jun 18 '14 at 18:05
@MikhailMorfikov: In theory, I believe so, but who knows what these programs are doing. Would want to see a more controlled environment with a simple program that just allocates say a gig of ram via Malloc. And then run the test after rebooting between tests. – Kyle Brandt Jun 18 '14 at 19:18
Ok, so I will stay with 0 for now. – Mikhail Morfikov Jun 18 '14 at 19:21
@MikhailMorfikov: Yes, practically I think 0 makes the most sense. In my environment, the only time I enable 1 is for Redis, which does stuff where it expects do be asking for a lot more memory that it is using due to a fork(). The child will pretty much use all the same memory pages, but Linux doesn't know that says to be safe it has to assume 2x memory will be used (if you want to learn more: – Kyle Brandt Jun 18 '14 at 19:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.