Re: icps, shmmax and shmall - Shared Memory tuning
От | Martijn van Oosterhout |
---|---|
Тема | Re: icps, shmmax and shmall - Shared Memory tuning |
Дата | |
Msg-id | 20020429094533.A11827@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
|
Список | pgsql-general |
On Sun, Apr 28, 2002 at 04:24:19PM -0400, Tom Lane wrote: > dorian dorian <dorian37076@yahoo.com> writes: > > This was also in the logs - > > > Apr 26 09:34:17 mito kernel: Out of Memory: Killed > > process 21540 (postmaster). > > Ugh. There's not a lot we can do about the kernel deciding to kill us. Not good. > > The machine just stopped responding at 9:34 and had to > > be rebooted. Is there any way to prevent this from > > happening, via a configuration option in postgres? > > Perhaps you should talk to the kernel developers about why they can't > find more graceful ways of dealing with out-of-memory situations :-( It's a bit hard be more graceful when you have no physical memory and no swap available. Something has to give. And if one process happens to be chewing >90% of memory, the kernel decides it should be the target. > I am not sure exactly what Linux considers an out-of-memory situation. > If it's dependent on available swap space, then configuring more swap > would probably prevent this scenario. If only physical RAM counts, > you might need to buy more RAM, or configure Postgres with a smaller > shared_buffers value. 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... -- 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 по дате отправления: