|
|
 | | From: | Merlin Moncure | | Subject: | Re: which dual-CPU hardware/OS is fastest for PostgreSQL? | | Date: | Fri, 14 Jan 2005 12:22:50 -0500 |
|
|
 | Alex wrote:
> Without starting too much controvesy I hope, I would seriously
> recommend you evaluate the AMCC Escalade 9500S SATA controller. It
> has many of the features of a SCSI controler, but works with cheaper
> drives, and for half the price or many SCSI controlers (9500S-8MI goes
> for abour $500). See http://plexq.com/~aturner/3ware.pdf for their 4
> way, 8 way and 12 way RAID benchmarks including RAID 0, RAID 5 and
> RAID 10. If others have similar data, I would be very interested to
> see how it stacks up against other RAID controllers.
At the risk of shaming myself with another 'me too' post, I'd like to
say that my experiences back this up 100%. The Escalade controllers are
excellent and the Raptor drives are fast and reliable (so far). With
the money saved from going SCSI, instead of a RAID 5 a 10 could be built
for roughly the same price and capacity, guess which array is going to
be faster?
I think the danger about SATA is that many SATA components are not
server quality, so you have to be more careful about what you buy. For
example, you can't just assume your SATA backplane has hot swap lights
(got bit by this one myself, heh).
Merlin
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
|
|
| | From: | Greg Stark | | Subject: | Re: which dual-CPU hardware/OS is fastest for PostgreSQL? | | Date: | 14 Jan 2005 13:47:34 -0500 |
|
|
| Josh Berkus writes:
> Merlin,
>
> > I think the danger about SATA is that many SATA components are not
> > server quality, so you have to be more careful about what you buy. For
> > example, you can't just assume your SATA backplane has hot swap lights
> > (got bit by this one myself, heh).
>
> Yeah, that's my big problem with anything IDE. My personal experience of
> failure rates for IDE drives, for example, is about 1 out of 10 fails in
> service before it's a year old; SCSI has been more like 1 out of 50.
Um. I'm pretty sure the actual hardware is just the same stuff. It's just the
interface electronics that change.
> Also, while I've seen benchmarks like Escalade's, my real-world experience has
> been that the full bi-directional r/w of SCSI means that it takes 2 SATA
> drives to equal one SCSI drive in a heavy r/w application. However, ODSL is
> all SCSI so I don't have any numbers to back that up.
Do we know that these SATA/IDE controllers and drives don't "lie" about fsync
the way most IDE drives do? Does the controller just automatically disable the
write caching entirely?
I don't recall, did someone have a program that tested the write latency of a
drive to test this?
--
greg
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
|
|
| | From: | Josh Berkus | | Subject: | Re: which dual-CPU hardware/OS is fastest for PostgreSQL? | | Date: | Fri, 14 Jan 2005 09:36:08 -0800 |
|
|
| Merlin,
> I think the danger about SATA is that many SATA components are not
> server quality, so you have to be more careful about what you buy. For
> example, you can't just assume your SATA backplane has hot swap lights
> (got bit by this one myself, heh).
Yeah, that's my big problem with anything IDE. My personal experience of
failure rates for IDE drives, for example, is about 1 out of 10 fails in
service before it's a year old; SCSI has been more like 1 out of 50.
Also, while I've seen benchmarks like Escalade's, my real-world experience has
been that the full bi-directional r/w of SCSI means that it takes 2 SATA
drives to equal one SCSI drive in a heavy r/w application. However, ODSL is
all SCSI so I don't have any numbers to back that up.
But one of my clients needs a new docs server, so maybe I can give an Escalade
a spin.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
|
|
|
