Re: icps, shmmax and shmall - Shared Memory tuning - Mailing list pgsql-general

From Tom Lane
Subject Re: icps, shmmax and shmall - Shared Memory tuning
Date
Msg-id 11874.1020025459@sss.pgh.pa.us
Whole thread Raw
In response to Re: icps, shmmax and shmall - Shared Memory tuning  (dorian dorian <dorian37076@yahoo.com>)
Responses Re: icps, shmmax and shmall - Shared Memory tuning
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: How to track down inconsistent performance?
Next
From: Brent Wood
Date:
Subject: Re: intel vs amd benchmark for pg server