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 free with the the Committed_AS number from /proc/meminfo. Although right now is not the best time to run the numbers on our machines (everyone is on vacation and so usage is low), the results for our login servers range from 64% to 34% of the committed address space being actually in use (at most); even most of our compute servers are using noticeably less than the committed AS.

(Feel free to run this test on your own machines and see what the results are. Note that free's numbers are not really the amount of user space memory used, and generally are higher. I'm not sure if it's possible to get actual numbers for just user space memory usage.)

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.)

Comments on this page:

From at 2009-12-25 06:55:00:

Swell in theory, but as you may or may not recall, I changed it on my instructional multi-user login servers when I started occasionally having one kernel panic due to, well, more airline passengers actually showing up than there were seats, so to speak. (On the single-user workstations, I'm quite sure I'm leaving it default, and it makes perfect sense that I should.)


By cks at 2009-12-31 22:25:03:

I'll agree that there are situations where non-strict overcommit isn't the right answer. I'm just arguing that it's not a stupid or silly default for Linux to be using.

(And I expect that we'll leave our main machines with strict overcommit, especially on the compute servers; there I believe that we have to assume that people sooner or later will really use all the memory because, well, people have in the past.)

Written on 25 December 2009.
« The advantages of open source software RAID
Things that limit the performance of hardware acceleration »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Dec 25 01:38:45 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.