| 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.
| 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 |