Two general comments: most people find that Opterons perform much better than Xeons. With some versions of PostgreSQL, the difference is over 50%. RAID5 generally doesn't make for a fast database. The problem is that there is a huge amount of overhead everytime you go to write something out to a RAID5 array. With careful tuning of the background writer you might be able to avoid some of that penalty, though your read performance will likely still be affected by the write overhead. BTW, -performance is a better list for info about this. If you look in the archives you'll be able to read a lot of threads from people seeking hardware advice. On Thu, Nov 17, 2005 at 09:54:38AM -0500, Michael D. Sofka wrote: > We are running PostgreSQL as the back-end to a spam scanning system. The > database holds suspected spam, and user configuration information. A > web interface allows people to accept, or (usually) discard the trapped > messages. So, most data is write once, read at most once, delete. > > The total size of the db is about 16gig in size. And, we expect it > could grow to 4 times this as more users are opted into spam scanning. > During most of the day, the machine is only lightly loaded. There are > two bursts of activity: the nightly vacuum, and the first thing in the > morning spam checking. > > Our current db machine has two hyper-threaded 2.4 GHz Xeon processors, 4 > gig of main memory, and is attached to a JBOD configured with RAID 5 for > the database, and mirrored disks for the DB logs. > > It is time to upgrade the machine. Two possibilities present themselves. > > 1. PowerEdge 6850 > 4 3.16 GHz Xeon processors > 16 gig of memory > Internal RAID 5 (only 3 disks) > 2 Mirrored disks for root and db log. > > 2. PowerEdge 2850 > 2 Dual core 2.8GHz Xeon processors > 8 gig of memory > JBOD with RAID 5, and mirrored db log. > > Both configurations will cost about the same, within $\Delta$ for an > acceptable value of $\Delta$. The idea behind the first is to keep the > entire database in memory, by way of the disk cache. Alas, to keep it > affordable (The extra memory is expensive) the JBOD must be jettisoned. > The second is a larger version of our current configuration. (The 6850 > with a JBOD would stretch the budget beyond $\Delta$, and the expense > would be difficult to justify.) > > I'm looking for any comments, or suggestions. With expected growth, the > first configuration seems out of balance---it will likely start off > fast, but with growth the slower disk configuration will likely be a > problem. Is anybody running PostgreSQL in a large memory, slower disk > configuration? What are your experiences. > > Thank You, > > Mike > > P.S. We are investigating if the current IBM JBOD will work with the > Dell PERC cards. But, even if they do, the current JBOD is populated > with soon to be extended warranty disks, and so progressively costly. > > -- > Michael D. Sofka sofkam@xxxxxxx > C&CT Sr. Systems Programmer Email, TeX, epistemology. > Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
