From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Linux2.6 overcommit behaviour |
Date: | 2003-08-31 14:02:08 |
Message-ID: | 3F51FFE0.4080503@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | ohp | 2003-08-31 14:36:52 | pg_dump bug? |
Previous Message | Kaare Rasmussen | 2003-08-31 13:22:08 | Re: FE/BE Protocol - Specific version |