Re: Linux2.6 overcommit behaviour

From: Manfred Spraul <manfred(at)colorfullife(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Linux2.6 overcommit behaviour
Date: 2003-08-30 20:18:16
Message-ID: 3F510688.1050709@colorfullife.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-08-30 21:25:59 Re: massive quotes?
Previous Message Joe Conway 2003-08-30 20:16:42 Re: database corruption