Re: icps, shmmax and shmall - Shared Memory tuning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: icps, shmmax and shmall - Shared Memory tuning
Дата
Msg-id 11874.1020025459@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: icps, shmmax and shmall - Shared Memory tuning  (dorian dorian <dorian37076@yahoo.com>)
Ответы Re: icps, shmmax and shmall - Shared Memory tuning  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
dorian dorian <dorian37076@yahoo.com> writes:
> This was also in the logs -

> Apr 26 09:34:17 mito kernel: Out of Memory: Killed
> process 21540 (postmaster).

Ugh.  There's not a lot we can do about the kernel deciding to kill us.

> The machine just stopped responding at 9:34 and had to
> be rebooted. Is there any way to prevent this from
> happening, via a configuration option in postgres?

Perhaps you should talk to the kernel developers about why they can't
find more graceful ways of dealing with out-of-memory situations :-(

I am not sure exactly what Linux considers an out-of-memory situation.
If it's dependent on available swap space, then configuring more swap
would probably prevent this scenario.  If only physical RAM counts,
you might need to buy more RAM, or configure Postgres with a smaller
shared_buffers value.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: How to track down inconsistent performance?
Следующее
От: Brent Wood
Дата:
Сообщение: Re: intel vs amd benchmark for pg server