Re: Hardware Recommendations

We're putting together specs for a nice PostgreSQL/FreeBSD server here and
I'd like some advice from some of you more experienced people out there.

Our dataset currently consists of a few dozen tables with anywhere from a
handful of records (lookup tables) to 65K records. There will be quite a few
INSERTs and UPDATEs (which also include more INSERTs via triggers), but the
majority of queries should still be SELECTs (with joins).

Future possible plans include increasing the number of SELECTs (once we are
sure that the server can handle the load), as well as adding a few hundred
tables of 50K records. Those 50K tables will be dropped and recreated on a
somewhat regular basis.

With all of that in mind... we were looking at a Dual PIII 1GHz w/2GB SDRAM
(god I love cheap RAM) and a 10K RPM SCSI drive. I'd love to hear any
suggestions, comments, etc. We'd also like to know if anyone recommends
upgrading to Xeons or quad processors.

Thanks!

Greg

> With all of that in mind... we were looking at a Dual PIII 1GHz w/2GB
SDRAM
> (god I love cheap RAM) and a 10K RPM SCSI drive. I'd love to hear any
> suggestions, comments, etc. We'd also like to know if anyone recommends
> upgrading to Xeons or quad processors.

I happen to run a quad Xeon, and at the time that we bought it, it was
the best machine we could get in terms of price for the performance that
we needed. However, there are some serious drawbacks. First and formost,
the 100 MHz bus is shared for all four processors, giving each processor
an effective 25 MHz bus under load. Not good. Also, Xeons and related
motherboards are very expensive, and the speeds don't go as high as the
commodity processors.

If I were to set up another machine now, I'd use a dual Athlon. For
not much more than the dual P3 would cost you, you could have a 2.4 GHz
machine with DDR RAM - and here's the real kicker, the dual Athlon boards
have a seperate 266 MHz bus to *each* processor, and a 266 MHz bus to the
RAM - so it's like each CPU having a 256 MHz bus to the chipset, and a 133
MHz bus to the RAM - about 5 times the bandwidth that a Xeon has in a
quad-configuration, and twice what a P3 would have. It's a win in every
regard over the Xeons and P3's, in my opinion.

As for the disk, the disk speed isn't terribly important, provided that
you're not using fsync() and have plenty of RAM for caching. On our quad
Xeon with 1.5 GB's, the disk lights only blink very occasionally.
However, we do use RAID 5 + hot spare for redundancy, so that a disk
failure won't take us down.

steve

The dual AMD board(s? I only know of one..) are *really* new, so I'd be
careful.... They sure do look nice though and aren't that expensive compares
to those quad Xeons...

A Note on Disks :
I respectfully disagree with Steve's "disk speed isn't terribly
important" -- it can be (and is totally dependent on what you're doing) and
since you have the on-board U160 with all the dual Athlon boards I've seen,
you might as well take full advantage of it.. That and you know Seagate has
those new 15,000 RPM U160 drives out *evil grin*..

A note on RAM :
Note that those dual Athlon boards take registered DDR RAM, which is a
little more expensive than your run-of-the-mill SDRAM (about twice(ish) as
much according to some numbers I just looked up). I wish I had something
going that needed that much horsepower so I could justify buying one!

Good luck!

> If I were to set up another machine now, I'd use a dual Athlon. For
> not much more than the dual P3 would cost you, you could have a 2.4 GHz
> machine with DDR RAM - and here's the real kicker, the dual Athlon boards
> have a seperate 266 MHz bus to *each* processor, and a 266 MHz bus to the
> RAM - so it's like each CPU having a 256 MHz bus to the chipset, and a 133
> MHz bus to the RAM - about 5 times the bandwidth that a Xeon has in a
> quad-configuration, and twice what a P3 would have. It's a win in every
> regard over the Xeons and P3's, in my opinion.
>
> As for the disk, the disk speed isn't terribly important, provided that
> you're not using fsync() and have plenty of RAM for caching. On our quad
> Xeon with 1.5 GB's, the disk lights only blink very occasionally.
> However, we do use RAID 5 + hot spare for redundancy, so that a disk
> failure won't take us down.

-Mitch

> I respectfully disagree with Steve's "disk speed isn't terribly
> important" -- it can be (and is totally dependent on what you're doing)
and
> since you have the on-board U160 with all the dual Athlon boards I've
seen,
> you might as well take full advantage of it.. That and you know Seagate
has
> those new 15,000 RPM U160 drives out *evil grin*..

You can't take advantage of U160 without at *least* three disks. ; )

If you have enough RAM for the cache, and you're not using fsync(), then
an insert/update doesn't actually hit the disk, it just returns. The
kernel can update the disk later at it's leisure. I'm not sorry that I
spent all of the money for the large array that I use, it provides
redundancy that lets me sleep easier - but I can guarantee that I'm not
using 1/100th of it's potential as far as write capabilities.

steve

Hi all,

One of my personal rules is that whenever someone says they're going to
get a 10K RPM SCSI drive, I always tell them to go 2 x 10K RPM SCSI
drives (half the size each) and do RAID 0. Or, preferably go 3 x and do
RAID 5.

My point is that 10K RPM drives are nice, but more is better (and
effective) with SCSI.

:)

Regards and best wishes,

Justin Clift

Steve Wolfe wrote:
>
> > I respectfully disagree with Steve's "disk speed isn't terribly
> > important" -- it can be (and is totally dependent on what you're doing)
> and
> > since you have the on-board U160 with all the dual Athlon boards I've
> seen,
> > you might as well take full advantage of it.. That and you know Seagate
> has
> > those new 15,000 RPM U160 drives out *evil grin*..
>
> You can't take advantage of U160 without at *least* three disks. ; )
>
> If you have enough RAM for the cache, and you're not using fsync(), then
> an insert/update doesn't actually hit the disk, it just returns. The
> kernel can update the disk later at it's leisure. I'm not sorry that I
> spent all of the money for the large array that I use, it provides
> redundancy that lets me sleep easier - but I can guarantee that I'm not
> using 1/100th of it's potential as far as write capabilities.
>
> steve
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

--
"My grandfather once told me that there are two kinds of people: those
who
work and those who take the credit. He told me to try to be in the first
group; there was less competition there."
- Indira Gandhi