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
overcommit, right?
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