Skip site navigation (1) Skip section navigation (2)

Re: icps, shmmax and shmall - Shared Memory tuning

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: dorian dorian <dorian37076(at)yahoo(dot)com>,pgsql-general(at)postgresql(dot)org
Subject: Re: icps, shmmax and shmall - Shared Memory tuning
Date: 2002-04-29 04:52:38
Message-ID: 20020429145238.A13163@svana.org (view raw or flat)
Thread:
Lists: pgsql-general
On Sun, Apr 28, 2002 at 11:47:19PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)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(at)svana(dot)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

In response to

Responses

pgsql-general by date

Next:From: Steve LaneDate: 2002-04-29 05:35:38
Subject: Postgres utils chewing RAM
Previous:From: Michael LoftisDate: 2002-04-29 04:39:03
Subject: Re: OIDs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group