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 по дате отправления: