Re: configurability of OOM killer

Поиск
Список
Период
Сортировка
От Florian G. Pflug
Тема Re: configurability of OOM killer
Дата
Msg-id 47A4D741.1060604@phlo.org
обсуждение исходный текст
Ответ на Re: configurability of OOM killer  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: configurability of OOM killer  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Tom Lane wrote:
> Another thought is to tell people to run the postmaster under a 
> per-process memory ulimit that is conservative enough so that the 
> system can't get into the regime where the OOM killer activates. 
> ulimit actually behaves the way we want, ie, it's polite about 
> telling you you can't have more memory ;-).

That will only work if postgres in the only service running on the
machine, though, no? If the postmaster and it's chilren use up 80% of
the available memory, then launching a forkbomb will still lead to the
postmaster being killed (Since it will get the most points). Or at least
this is how I interpret link posted originally.

And *if* postgres is the only service, does setting a ulimit have an
advantage over disabling memory overcommitting?

AFAICS, memory overcommit helps if a program creates 50mb of mosty
read-only data, and than forks 10 times, or if it maps a large amount of
memory but writes to that block only sparsely. Since postgres does
neither, a dedicated postgres server won't see any benefits from
overcommitting memory I'd think.

regards, Florian Pflug



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: configurability of OOM killer
Следующее
От: "Pavel Stehule"
Дата:
Сообщение: clone varlena function