From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Richard Troy <rtroy(at)ScienceTools(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>, Richard Huxton <dev(at)archonet(dot)com>, Russell Smith <mr-russ(at)pws(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Postgres server crash |
Date: | 2006-11-26 23:41:02 |
Message-ID: | 20061126234101.GG39519@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-11-27 00:51:43 | Re: Priority to a mission critical transaction |
Previous Message | Jim C. Nasby | 2006-11-26 23:33:48 | Re: availability of SATA vendors |