Re: Linux2.6 overcommit behaviour - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Linux2.6 overcommit behaviour
Date
Msg-id 3F51FFE0.4080503@dunslane.net
Whole thread Raw
In response to Re: Linux2.6 overcommit behaviour  (Manfred Spraul <manfred@colorfullife.com>)
Responses Re: Linux2.6 overcommit behaviour
List pgsql-hackers

Manfred Spraul wrote:

>>
>> It is strange to choose 50% of RAM plus swap (what if your spam is
>> small). I thought it would be 100% of RAM plus the swap that exceeds RAM
>> size.
>>  
>>
> Linux doesn't  release the swap file page when a page is read back: If 
> a page is only read by the user space app, then the swapped out page 
> remains valid, and thus the kernel can skip the write to disk on the 
> next swapout. Thus if you are paranoid, you must limit the total 
> address space to the size of your swap files.
> If your swap space (your wrote "spam" - I assume a typo) is small, 
> then you'll run into problems. It's recommended that your swap space 
> should be 2*physical memory. I assume that many oom killer reports are 
> from system with too small swap files, and then an updatedb run pushes 
> the system into oom.


I believe that the swap slot can be subsequently freed, though. In 
theory your available virtual memory should be (almost) RAM+swap. In 
practice, Linux can run too close to that limit, (or way over it if you 
turn the checks off). But restricting the maximum possible pages to 
RAM/2 + swap should normally be fine. IANAKH, though.

Also note that the truly bad thing about the OOM killer is that it can 
affect a process that is not making any new memory demands at all.

cheers

andrew



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: massive quotes?
Next
From: Kurt Roeckx
Date:
Subject: Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)