Re: Max shared_buffers

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Max shared_buffers
Дата
Msg-id 47F51AC8.2040309@postnewspapers.com.au
обсуждение исходный текст
Ответ на Re: Max shared_buffers  ("Andrej Ricnik-Bay" <andrej.groups@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Scott Marlowe"
Дата:
Сообщение: Re: Max shared_buffers
Следующее
От: "Matt Klinker"
Дата:
Сообщение: Query plan excluding index on view