[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Swapper problems?

David Given wrote:
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
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.

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 mallocs succeed 2 - sane - don't overcommit - only grant a malloc if virtual memory is available, where the amount of virtual memory available = swap + RAM*(overcommit_ratio/100)

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.


Reply to: