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

From Martijn van Oosterhout
Subject Re: icps, shmmax and shmall - Shared Memory tuning
Date
Msg-id 20020429121113.A12744@svana.org
Whole thread Raw
In response to Re: icps, shmmax and shmall - Shared Memory tuning  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: icps, shmmax and shmall - Shared Memory tuning
List pgsql-general
On Sun, Apr 28, 2002 at 08:12:56PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > 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...
>
> The problem here is that the *postmaster* is getting killed.  It's not
> the one consuming excess memory (assuming that the underlying problem
> is a runaway query, which seems plausible).

It depends on what version you're running. I used to be that it simply
killed whatever process asked for the memory when it run out. As you point
out, occasionally that was init. In the cases of the postmaster, it's
probably one of accept(), connect() or select() that's running out of
memory.

> In any case, why is "kill -9 some process" an appropriate behavior?
> Sane kernels return an error on sbrk(2) if they don't have any more
> memory to give out...

The problem is that sbrk merely extends your memory map, the memory is not
actually allocated until it is used, i.e. it's overcomitting memory. The
actual running out of memory will occur in a page fault rather than sbrk()
failing. This overcomitting is somewhat optional, depending on your OS. As
noted above, other system calls also allocate memory, notably select() and
poll(), though read() and write() also.

> I suppose people who see this happen a lot might consider launching the
> postmaster as an inittab entry --- if init sees the postmaster die, it
> should restart it.  Although if old backends are still running, this
> isn't necessarily going to fix anything.  (And it seems to me I have
> heard that the Linux kernel is willing to gun down init too, so relying
> on init to survive a memory crunch may be wishful thinking.)

The "kill large processes" is recent when people started complaining about
init being killed. They should have just told these people "get more
swap/buy more memory/fix your program" rather than spend ages debating which
process is the right one to kill...
--
Martijn van Oosterhout   <kleptog@svana.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

pgsql-general by date:

Previous
From: Joe Conway
Date:
Subject: Re: OIDs
Next
From: Michael Loftis
Date:
Subject: Re: intel vs amd benchmark for pg server part 2