Knight, Doug wrote: > Hi, > As a gauge, we recently purchased several servers as our systems get > close to going operational. We bought Dell 2900s, with the cheapest quad > core processors (dual) and put most of the expense into lots of drives > (8 15K 146GB SAS drives in a RAID 10 set), and the PERC 6 embedded > controller with 512MB battery backed cache. That gives us more spindles, > the RAID redundancy we want, plus the high, reliable throughput of the > BBC. The OS (and probably WAL) will run on a RAID 1 pair of 15K 76GB > drives. We also went with 8GB memory, which seemed to be the price cost > point in these systems (going above 8GB had a much higher cost). > Besides, in our prototyping, or systems had 2GB, which we rarely > exceeded, so 8GB should be plently (and we can always expand). > > So really, if you can save money on processors by going Opteron (and > your IT department doesn't have an Intel-based system requirement like > ours), put what you save into a good disk I/O subsystem. Hope that > helps. > Top posting? Bleee ;-) How to read now? OK I know that IO is most important for database but: I'm sorry, my question is about processor/platform choice? :-) I have to buy new server and I want optimal one. Like I've wrote in different email my IO subsystem is quite good for now. ps. To admin of that list: what is with Reply-to on that list? > Doug > > -----Original Message----- > From: pgsql-performance-owner@xxxxxxxxxxxxxx > [mailto:pgsql-performance-owner@xxxxxxxxxxxxxx] On Behalf Of Adam Tauno > Williams > Sent: Friday, May 23, 2008 8:22 AM > To: pgsql-performance > Subject: Re: [PERFORM] Quad Xeon or Quad Opteron? > > >> Also, based on what I've seen on this list rather than personal >> experience, you might want to give more thought to your storage than >> > to > >> CPU power. The usual thrust of advice seems to be: Get a fast, battery >> backed RAID controller. "Fast" does not mean "fast sequential I/O in >> ideal conditions so marketing can print a big number on the box"; you >> need to consider random I/O too. Get lots of fast disks. Get enough >> > RAM > >> to ensure that your indexes fit in RAM if possible. >> Note, however, that I have no direct experience with big Pg databases; >> I'm just trying to provide you with a guide of what information to >> provide and what to think about so you can get better answers here >> > from > >> people who actually have a clue. >> > > Yep, we've had PostreSQL databases for a long time. The various > current generation processors, IMO, have no substantive difference in > practice; at least not relative to the bang-for-the-buck or more RAM > and good I/O. > > >
