Re: icps, shmmax and shmall - Shared Memory tuning

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: dorian dorian <dorian37076(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: icps, shmmax and shmall - Shared Memory tuning
Date: 2002-04-29 02:11:13
Message-ID: 20020429121113.A12744@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, Apr 28, 2002 at 08:12:56PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)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(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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Loftis 2002-04-29 02:18:36 Re: intel vs amd benchmark for pg server part 2
Previous Message Joe Conway 2002-04-29 00:47:44 Re: OIDs