Re: Postgres server crash

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Postgres server crash
Дата
Msg-id 20061126234101.GG39519@nasby.net
обсуждение исходный текст
Ответ на Re: Postgres server crash  (Richard Troy <rtroy@ScienceTools.com>)
Ответы Re: Postgres server crash  (Michael Stone <mstone+postgres@mathom.us>)
Re: Postgres server crash  (Florian Weimer <fw@deneb.enyo.de>)
Список 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 по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: availability of SATA vendors
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Priority to a mission critical transaction