Re: Max shared_buffers - Mailing list pgsql-performance

From Craig Ringer
Subject Re: Max shared_buffers
Date
Msg-id 47F51AC8.2040309@postnewspapers.com.au
Whole thread Raw
In response to Re: Max shared_buffers  ("Andrej Ricnik-Bay" <andrej.groups@gmail.com>)
List pgsql-performance
Andrej Ricnik-Bay wrote:
> On 04/04/2008, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> Not entirely true.  on 32 bit OS / software, the limit is just under 2
>>  Gig.

That depends on the OS. On Linux it's AFAIK closer to 3GB because of
less address space being consumed by the kernel, though I think free app
address space might be further reduced with truly *massive* amounts of
RAM. There are patches (the "4GB/4GB" patches) that do dodgy address
space mapping to support a full 4GB application address space.

> Where do you get that figure from?
>
> There's an architectural (theoretical) limitation of RAM at 4GB,
> but with the PAE (that pretty much any CPU since the Pentium Pro
> offers) one can happily address 64GB on 32-bit.

The OS can address more than 4GB of physical RAM with PAE, yes.

However, AFAIK no single process may directly use more than (4GB -
kernel address space requirements) of RAM without using special
extensions like address space windowing. Of course, they still benefit
from the extra RAM indirectly through bigger disk caches, less
competition with other processes for free physical RAM, etc.

As Pg uses a multiprocess model I imagine individual backends can make
use of a large amount of RAM (as work_mem etc), though the address space
consumed by the shared memory will limit how much it can use.

There's a decent, if Microsoft-specific, article about PAE here:

http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx


--
Craig Ringer

pgsql-performance by date:

Previous
From: "Scott Marlowe"
Date:
Subject: Re: Max shared_buffers
Next
From: "Matt Klinker"
Date:
Subject: Query plan excluding index on view