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@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] 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.
>
>
>
