Re: Postgres server crash - Mailing list pgsql-performance

From Jim C. Nasby
Subject Re: Postgres server crash
Date
Msg-id 20061126234101.GG39519@nasby.net
Whole thread Raw
In response to Re: Postgres server crash  (Richard Troy <rtroy@ScienceTools.com>)
Responses Re: Postgres server crash  (Michael Stone <mstone+postgres@mathom.us>)
Re: Postgres server crash  (Florian Weimer <fw@deneb.enyo.de>)
List pgsql-performance
On Sat, Nov 18, 2006 at 05:28:46PM -0800, Richard Troy wrote:
> <soapbox> ...I read a large number of articles on this subject and am
> absolutely dumbfounded by the -ahem- idiots who think killing a random
> process is an appropriate action. I'm just taking their word for it that
> there's some kind of impossibility of the existing Linux kernel not
> getting itself into a potentially hung situation because it didn't save
> itself any memory. Frankly, if it takes a complete kernel rewrite to fix
> the problem that the damned operating system can't manage its own needs,
> then the kernel needs to be rewritten! </soapbox>
>
> These kernel hackers could learn something from VAX/VMS.

What's interesting is that apparently FreeBSD also has overcommit (and
IIRC no way to disable it), yet I never hear people going off on OOM
kills in FreeBSD. My theory is that FreeBSD admins are smart enough to
dedicate a decent amount of swap space, so that by the time you got to
an OOM kill situation you'd be so far into swapping that the box would
be nearly unusable. Many linux 'admins' think it's ok to save a few GB
of disk space by allocating a small amount of swap (or none at all), and
*kaboom*.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: availability of SATA vendors
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Priority to a mission critical transaction