Rory Campbell-Lange wrote:

I'm thinking of upgrading an existing dedicated server and colocating my
own server.

The server is used for prototype systems running Postgresql, php and
apache. The largest database is presently under 10GB and I haven't had
any major performance problems. We expect to have to host larger data
sets in the next year and anticipate one or two databases reaching the
30GB mark in size. We write a lot of our webapps functionality using

The present server is a 2GHz Pentium 4/512 KB cache with 2
software-raided ide disks (Maxtors) and 1GB of RAM.

I have been offered the following 1U server which I can just about afford:

1U server
Intel Xeon 2.8GHz 512K cache                      1
512MB PC2100 DDR ECC Registered                   2
80Gb SATA HDD                                     4
4 port SATA card, 3 ware 8506-4                   1
3 year next-day hardware warranty                 1

There is an option for dual CPUs.

I intend to install the system (Debian testing) on the first disk and
run the other 3 disks under RAID5 and ext3.

If you are going to spend your money anywhere, spend it on your disk subsystem. More or less, depending on the application, the bottleneck in your database performance will be the number of random IO operations per second (IOPS) your disk subsystem can execute. If you've got the money, get the largest (i.e. most spindles) RAID 10 (striped and mirrored) you can buy. If your budget doesn't permit RAID 10, RAID 5 is probably your next best bet.

I'm fairly ignorant about the issues relating to SATA vs SCSI and what
the best sort of RAM is for ensuring good database performance. I don't
require anything spectacular, just good speedy general performance.

Be sure that if you go with SATA over SCSI, the disk firmware does not lie about fsync(). Most consumer grade IDE disks will report to the OS that data is written to disk while it is still in the drive's cache. I don't know much about SATA disks, but I suspect they behave the same way. The problem with this is that if there is data that PostgreSQL thinks is written safely to disk, but is really still in the drive cache, and you lose power at that instant, you can find yourself with an inconsistent set of data that cannot be recovered from. SCSI disks, AFAIK, will always be truthful about fsync(), and you will never end up with data that you *thought* was written to disk, but gets lost on power failure.

I imagine dedicating around 25% of RAM to Shared Memory and 2-4% for
Sort memory.

That is probably too much RAM to allocate to shm. Start with 10000 buffers, benchmark your app, and slowly work up from there. NOTE: This advice will likely change with the introduction of ARC (adaptive caching) in 8.0; for now what will happen is that a large read of an infrequently accessed index or table will blow away all your shared memory buffers, and you'll end up with 25% of your memory filled with useless data. Better to let the smarter filesystem cache handle the bulk of your caching needs.

Comments and advice gratefully received.

Best Luck,

Bill Montgomery

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
     joining column's datatypes do not match

Reply via email to