Re: icps, shmmax and shmall - Shared Memory tuning - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: icps, shmmax and shmall - Shared Memory tuning
Date
Msg-id 20020429145238.A13163@svana.org
Whole thread Raw
In response to Re: icps, shmmax and shmall - Shared Memory tuning  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: icps, shmmax and shmall - Shared Memory tuning
List 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 by date:

Previous
From: Michael Loftis
Date:
Subject: Re: OIDs
Next
From: Steve Lane
Date:
Subject: Postgres utils chewing RAM