Re: icps, shmmax and shmall - Shared Memory tuning

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: icps, shmmax and shmall - Shared Memory tuning
Дата
Msg-id 20020429145238.A13163@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  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Список pgsql-general
On Sun, Apr 28, 2002 at 11:47:19PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > 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.  I shall recommend other Unixen to anyone who wants
> to run reliable applications.  (HPUX for example; which has plenty of
> faults, but at least it keeps track of how much space it can promise.)

I'm not saying it's a good idea. Indeed, people saying all the time it's
bad. But it is the default. If people don't like then they should set the
over_commit sysctl off (I forget the exact name).
--
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 по дате отправления:

Предыдущее
От: Michael Loftis
Дата:
Сообщение: Re: OIDs
Следующее
От: Steve Lane
Дата:
Сообщение: Postgres utils chewing RAM