Re: Preventing OOM kills

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: John R Pierce <pierce(at)hogranch(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Preventing OOM kills
Date: 2011-05-25 01:09:16
Message-ID: BANLkTim5r+Q5H-zv9UWu6=CZPyQDEJ8yEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, May 24, 2011 at 7:01 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> On 05/24/11 5:50 PM, Andrej wrote:
>>
>> Add more RAM?  Look at tunables for other processes on
>> the machine?  At the end of the day making the kernel shoot
>> anything out of despair shouldn't be the done thing.
>
> somehow, 'real' unix has neither a OOMkiller nor does it flat out die under
> heavy loads, it just degrades gracefully.  I've seen Solaris and AIX and BSD
> servers happily chugging along with load factors in the 100s, significant
> portions of memory paging, etc, without completely crumbling to a halt.
>  Soimetimes I wonder why Linux even pretends to support virtual memory, as
> you sure don't want it to be paging.

I've found that on servers with multiple drives and the page file
spread across them linux does pretty well when swapping out. Even
going pretty far back, when I had 6 9G SCSI drives on an old Sparc 20
running RHEL with 256M ram the swapping was quite speedy with a 100M
or so on each drive.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2011-05-25 01:59:23 Re: unable to restore. pg_restore: implied data-only restore
Previous Message Tim Uckun 2011-05-25 01:03:55 unable to restore. pg_restore: implied data-only restore