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.

---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings

Reply via email to