Re: Swapper problems?
David Given wrote:
overcommit_memory=2 will guarantee that every page is backed by memory
or swap (assuming overcommit_ratio is less than ~90%). 2 is what you want.
Matthew Palmer wrote:
You really, *really* don't want to set your overcommit ratio to 95... you
can very easily starve the kernel of memory (which, as you'd expect, it kind
of a bad thing). I've had problems with any setting greater than 80, so I
just leave it at the default (50) and give myself more swap if I need it.
The problem is that I've got lots of swap, and it's nearly all unused,
but am getting page allocation failures *anyway*. I don't think this is
correct behaviour, and am looking for a workaround.
Although if I've understood things correctly, this will tell me system
to behave as if it's actually got 2GB of RAM (512MB RAM + 1GB swap +
(1*0.95) GB of overcommit).
Not quite. It's 1GB swap + 0.95 * 512MB = ~1.45GB.
Do you mean 512MB RAM + 1GB swap + (0.95 * 512MB) overcommit = 2022MB of
total VM? Otherwise I'd be overcommitting to *less* memory than I would
have with it all turned off...
Well, overcommit_memory=2 *is* turning off overcommit; the (slightly
misnamed) overcommit_ratio just gives the kernel a baseline for working out
when it might be getting to the overcommit point.
Okay, now I'm just confused. Accorded to the linked docs,
overcommit_memory=0 means that allocations only succeed if RAM+swap
allow, 1 means that all allocations succeed and page fault later if page
allocation fails, and 2 means that it will allow allocations under some
circumstances (controlled by the ratio). So 2 is still allowing
I suspect that in interests of sanity, I want overcommit_memory=0, which
should mean (if I've understood things correctly) that every page that
an application gets from the kernel is guaranteed to be backed by a page
of RAM or swap. I'll then see if that improves things
setting overcommit_memory=0 is the default. It will gladly give more
more pages than available RAM+swap under certain conditions (usually
when doing lots of small mallocs). It's based on a heuristic. I'm sorry
for linking to a misleading article. 2 does not allow overcommiting
(with ratio < 100%)
I was confused and angry the first time I found this out because I had
some multi-user systems crash multiple times because of this. The
default (overcommit_memory=0 ) is not sane and will happily allow more
memory to be allocated than exists in RAM+swap.
For clarity, here is what the values of overcommit_memory do:
0 - sometimes overcommit, based on a heuristic.
1 - always overcommit -- never checks if enough RAM is available. all
2 - sane - don't overcommit - only grant a malloc if virtual memory is
available, where the amount of virtual memory available = swap +
It is probably best to leave overcommit_ratio at the default of 50 based
on Matt Palmer's reply, because the kernel uses different memory calls.
I hope this clarifies things.