On Mon, Aug 24, 2009 at 09:50:26PM +0100, David Given wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
Then overcommit_memory=2 is not what you are looking for.
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?
No.
Otherwise I'd be overcommitting to *less* memory than I would
have with it all turned off...
Exactly.
[...]
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,
Which docs are these?
I go from
/usr/share/doc/linux-doc-2.6.26/Documentation/vm/overcommit-accounting.gz
overcommit_memory=0 means that allocations only succeed if RAM+swap
allow,
No, 0 = Heuristic overcommit handling ("educated guess" mode).
1 means that all allocations succeed and page fault later if page
allocation fails,
Mmmm, not quite -- "page fault" doesn't mean what you think it means. A
page fault is an ordinary virtual memory operation; if page allocation
fails, then you get the OOM killer and all manner of unpleasantness.
and 2 means that it will allow allocations under some
circumstances (controlled by the ratio). So 2 is still allowing
overcommit, right?
No. I suspect you misunderstand the meaning of "overcommit". It doesn't
mean "use more memory than you have physical memory", it means "use more
memory than you have *virtual* memory".
In fact, if you'd read the above file, you'd see:
2 - Don't overcommit.
Which is fairly unequivocal.
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.
If that's what you want, then the closest you'll get is with
overcommit_memory=2. Sticking with the default value of overcommit_ratio
(50) is more likely to produce the desired result than setting it to 95
(which, in my extensive experience playing with this stuff, is almost
guaranteed to produce problems), because the kernel's memory usage isn't
accounted for in the overcommit calculations, and hence you'll hit the OOM
handler far earlier.
I really don't think that jiggering with overcommit is what you want to be
doing, though; your problems appear to be much more interesting than that.
- Matt