Re: Pre-allocation of shared memory ... - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Pre-allocation of shared memory ...
Date
Msg-id 87smqek8zv.fsf@stark.dyndns.tv
Whole thread Raw
In response to Re: Pre-allocation of shared memory ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> I see no reason RAM can't be used as backing store for possible
> copy-on-write use.

Depends on the scenario. For a database like postgres it would work fairly
well since that RAM is still available for filesystem buffers. For Oracle it
would suck because it's not available for Oracle to allocate to use for its
own buffers. And for a web server with an architecture like Apache it would
suck because it would mean being restricted to a much lower number of
processes than the machine could really handle.

> > I'm still wondering what the "no overcommit handling" option does,
> > exactly.
> 
> I assume it does no kills, and allows you to commit until you run of of
> swap and hang.  This might be the BSD 4.4 behavior, actually.

I think it just makes fork/mmap/sbrk return an error if you run out of swap.
That makes the error appear most likely as malloc() returning null which most
applications don't handle anyways and the user sees the same behaviour:
programs crashing randomly.

Of course that's not what high availability server software does but since
most users' big memory consumers these days seem to be their window manager
and its 3d animated window decorations...

-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CVS -Tip compile issue -- FreeBSD 4.8
Next
From: "Ron Mayer"
Date:
Subject: Re: Pre-allocation of shared memory ...