Re: icps, shmmax and shmall - Shared Memory tuning

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: icps, shmmax and shmall - Shared Memory tuning
Дата
Msg-id 20020429121113.A12744@svana.org
обсуждение исходный текст
Ответ на Re: icps, shmmax and shmall - Shared Memory tuning  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: icps, shmmax and shmall - Shared Memory tuning  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: OIDs
Следующее
От: Michael Loftis
Дата:
Сообщение: Re: intel vs amd benchmark for pg server part 2