Jeff Bohmer wrote:
> It seems I don't fully understand the bigmem situation. I've searched
> the archives, googled, checked RedHat's docs, etc. But I'm getting
> conflicting, incomplete and/or out of date information. Does anyone
> have pointers to bigmem info or configuration for the 2.4 kernel?
Bigmem is the name for Linux's PAE support.
> If Linux is setup with 2GB for kernel and 2GB for user, would that be OK
> with a DB size of 2-2.5 GB? I'm figuring the kernel will cache most/all
> of the DB in it's 2GB and there's 2GB left for PG processes. Where does
> PG's SHM buffers live, kernel or user? (I don't plan on going crazy
> with buffers, but will guess we'd need about 128MB, 256MB at most.)
PG's SHM buffers live in user. Whether Linux's OS caches lives in user
or kernel, I think it's in kernel and I remember reading a max of ~950KB
w/o bigmem which means your 3.5GB of available OS memory will definitely
have to be swapped in and out of kernel space using PAE.
>> Well if this is the case, you probably should get an Opteron server
>> *now* and just run 32-bit Linux on it until you're sure about the
>> software. No point in buying a Xeon and then throwing the machine away
>> in a year when you decide you need 64-bit for more speed.
> That's a good point. I had forgotten about the option to run 32bit on
> an Operton. If we had 3GB or 4GB initially on an Opteron, we'd need
> bigmem for 32bit Linux, right?
> This might work nicely since we'd factor in the penalty from PAE for now
> and have the performance boost from moving to 64bit available on
> demand. Not having to build another DB server in a year would also be
> FYI, we need stability first and performance second.
We ordered a 2x Opteron server the moment the CPU was released and it's
been perfect -- except for one incident where the PCI riser card had
drifted out of the PCI slot due to the heavy SCSI cables connected to
I think most of the Opteron server MBs are pretty solid but you want
extra peace-of-mind, you could get a server from Newisys as they pack in
a cartload of extra monitoring features.
In response to
pgsql-performance by date
|Next:||From: Aram Kananov||Date: 2003-12-12 01:17:06|
|Subject: Measuring execution time for sql called from PL/pgSQL|
|Previous:||From: scott.marlowe||Date: 2003-12-11 22:48:58|
|Subject: Re: Hardware suggestions for Linux/PGSQL server|