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