Linux's non-strict overcommit is the right default
December 25, 2009
I've written before about Linux's overcommit settings and the general background of virtual memory limits. Several years of experience of running various general use systems with strict overcommit and paying attention to the numbers have convinced me of something: non-strict overcommit is the right default on Linux, and probably on any modern Unix in general.
I have come to this view through experimental evidence, namely that all of our user login machines generally run with significant amounts of committed address space, yet they have lots of free memory and very little swap used. When they run alarmingly close to their strict overcommit limits (and they have), they are never under memory pressure; they are hitting an artificial limit.
Clearly a lot of programs do not use anywhere near all of their
committed address space, and you can get a general estimate of the
magnitude of the non-use by comparing the numbers from
(Feel free to run this test on your own machines and see what the
results are. Note that
The reality is that configuring our login servers for true strict overcommit would require heroic amounts of swap space, which has its own downsides. As it is, while we have strict overcommit turned on, we have the settings tuned to significantly overcommit real memory and we have too much swap configured (6 GB of swap on machines with 8 GB of memory), all in order to not run into what are now almost entirely artificial limits on committed address space.
It's not really surprising that this is the case, because strict overcommit has to be intensely pessimistic since it is making such a strong promise. Very few programs fork and then immediately scribble all over the copy-on-write virtual memory shared between parent and child, but strict overcommit has to assume that they all will, because it's promised that they can. Similarly, very few programs scribble on all of the code pages in shared libraries that they've mapped read-write (which is necessary in order to do relocation fixups), and in fact these days many may never touch any. But again, strict overcommit must assume that they will and it has to deliver on those promises. And so on, in all of the ways that programs may put claims on physical memory.
(See also this comment, especially its discussion of the various things that malloc does in the name of speed and efficient real memory use.)
(This entry was sparked by reading Jeff Davis's blog entry on the Linux OOM killer.)
* * *
Atom feeds are available; see the bottom of most pages.