On Sun, Apr 28, 2002 at 04:24:19PM -0400, Tom Lane wrote:
> dorian dorian <dorian37076(at)yahoo(dot)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 :-(
It's a bit hard be more graceful when you have no physical memory and no
swap available. Something has to give. And if one process happens to be
chewing >90% of memory, the kernel decides it should be the target.
> 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.
Adding more swap space definitly helps, but if you have a query that just
eats a lot of memory, it's better to fix the query...
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Canada, Mexico, and Australia form the Axis of Nations That
> Are Actually Quite Nice But Secretly Have Nasty Thoughts About America
In response to
pgsql-general by date
|Next:||From: Tom Lane||Date: 2002-04-29 00:12:56|
|Subject: Re: icps, shmmax and shmall - Shared Memory tuning |
|Previous:||From: Ron Snyder||Date: 2002-04-28 22:59:01|
|Subject: Re: How to track down inconsistent performance? |