Re: icps, shmmax and shmall - Shared Memory tuning
От | Arsalan Zaidi |
---|---|
Тема | Re: icps, shmmax and shmall - Shared Memory tuning |
Дата | |
Msg-id | 012101c1ef5c$d418a860$4301a8c0@directi.com обсуждение исходный текст |
Ответ на | Re: icps, shmmax and shmall - Shared Memory tuning (dorian dorian <dorian37076@yahoo.com>) |
Список | pgsql-general |
----- Original Message ----- From: Tom Lane <tgl@sss.pgh.pa.us> To: Martijn van Oosterhout <kleptog@svana.org> Cc: dorian dorian <dorian37076@yahoo.com>; <pgsql-general@postgresql.org> Sent: Monday, April 29, 2002 9:17 AM Subject: Re: [GENERAL] icps, shmmax and shmall - Shared Memory tuning > Martijn van Oosterhout <kleptog@svana.org> writes: > > On Sun, Apr 28, 2002 at 08:12:56PM -0400, Tom Lane wrote: > >> 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. > > And this is the application's fault? > > If Linux overcommits memory, then Linux is broken. Do not bother to > argue the point. IANAKH, but I believe Linux chooses to over-commit cause many programs asks for far more RAM than they ever use. It's a bit of a gamble for the kernel to allow memory overcommit, but it pays off most of the time. I think you can turn it off by placing the line vm.overcommit_memory = 0 in /etc/sysctl.conf --Arsalan.
В списке pgsql-general по дате отправления: