Re: icps, shmmax and shmall - Shared Memory tuning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
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 00:12:56
Message-ID: 12937.1020039176@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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).

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...

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.)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Philip Reimer 2002-04-29 00:16:04 OIDs
Previous Message Martijn van Oosterhout 2002-04-28 23:45:33 Re: icps, shmmax and shmall - Shared Memory tuning