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

From Manfred Spraul
Subject Re: Linux2.6 overcommit behaviour
Date
Msg-id 3F510688.1050709@colorfullife.com
Whole thread Raw
In response to Re: Linux2.6 overcommit behaviour  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Linux2.6 overcommit behaviour
List pgsql-hackers
Bruce Momjian wrote:

>Shridhar Daithankar wrote:
>  
>
>>Hi all,
>>
>>Following is from Documentation/vm/overcommit-accounting
>>-------------
>>2    -    (NEW) strict overcommit. The total address space commit
>>        for the system is not permitted to exceed swap + a
>>        configurable percentage (default is 50) of physical RAM.
>>        Depending on the percentage you use, in most situations
>>        this means a process will not be killed while accessing
>>        pages but will receive errors on memory allocation as
>>        appropriate.
>>    
>>
>
>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.

--   Manfred



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: database corruption
Next
From: Tom Lane
Date:
Subject: Re: massive quotes?