Re: Swapper problems?
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
Reply to: