Jeff Bohmer wrote:
> We're willing to shell out extra bucks to get something that will
> undoubtedly handle the projected peak load in 12 months with excellent
> performance. But we're not familiar with PG's performance on Linux and
> don't like to waste money.
Properly tuned, PG on Linux runs really nice. A few people have
mentioned the VM swapping algorithm on Linux is semi-dumb. I get around
that problem by having a ton of memory and almost no swap.
> I've been thinking of this (overkill? not enough?):
> 2 Intel 32-bit CPUs
> Lowest clock speed chip for the fastest available memory bus
> 4 GB RAM (maybe we only need 3 GB to start with?)
> SCSI RAID 1 for OS
> For PostgreSQL data and logs ...
> 15k rpm SCSI disks
> RAID 5, 7 disks, 256MB battery-backed write cache
> (Should we save $ and get a 4-disk RAID 10 array?)
>
> I wonder about the 32bit+bigmem vs. 64bit question. At what database
> size will we need more than 4GB RAM?
With 4GB of RAM, you're already running into bigmem. By default, Linux
gives 2GB of address space to programs and 2GB to kernel. I usually see
people quote 5%-15% penalty in general for using PAE versus a flat
address space. I've seen simple MySQL benchmarks where 64-bit versions
run 35%+ faster versus 32-bit+PAE but how that translates to PG, I dunno
yet.
> We'd like to always have enough RAM to cache the entire database. While
> 64bit is in our long-term future, we're willing to stick with 32bit
> Linux until 64bit Linux on Itanium/Opteron and 64bit PostgreSQL "settle
> in" to proven production-quality.
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.