Re: How to improve db performance with $7K?

Well - unfortuantely software RAID isn't appropriate for everyone, and
some of us need a hardware RAID controller.  The LSI Megaraid 320-2
card is almost exactly the same price as the 3ware 9500S-12 card
(although I will conceed that a 320-2 card can handle at most 2x14
devices compare with the 12 on the 9500S).

If someone can come up with a test, I will be happy to run it and see
how it goes.  I would be _very_ interested in the results having just
spent $7k on a new DB server!!

I have also seen really bad performance out of SATA.  It was with
either an on-board controller, or a cheap RAID controller from
HighPoint.  As soon as I put in a decent controller, things went much
better.  I think it's unfair to base your opinion of SATA from a test
that had a poor controler.

I know I'm not the only one here running SATA RAID and being very
satisfied with the results.

Thanks,

Alex Turner
netEconomist

On Apr 6, 2005 4:01 PM, William Yu <wyu@talisys.com> wrote:
> It's the same money if you factor in the 3ware controller. Even without
> a caching controller, SCSI works good in multi-threaded IO (not
> withstanding crappy shit from Dell or Compaq). You can get such cards
> from LSI for $75. And of course, many server MBs come with LSI
> controllers built-in. Our older 32-bit production servers all use Linux
> software RAID w/ SCSI and there's no issues when multiple
> users/processes hit the DB.
>
> *Maybe* a 3ware controller w/ onboard cache + battery backup might do
> much better for multi-threaded IO than just plain-jane SATA.
> Unfortunately, I have not been able to find anything online that can
> confirm or deny this. Hence, the choice is spend $$$ on the 3ware
> controller and hope it meets your needs -- or spend $$$ on SCSI drives
> and be sure.
>
> Now if you want to run such tests, we'd all be delighted with to see the
> results so we have another option for building servers.
>
>
> Alex Turner wrote:
> > It's hardly the same money, the drives are twice as much.
> >
> > It's all about the controller baby with any kind of dive.  A bad SCSI
> > controller will give sucky performance too, believe me.  We had a
> > Compaq Smart Array 5304, and it's performance was _very_ sub par.
> >
> > If someone has a simple benchmark test database to run, I would be
> > happy to run it on our hardware here.
> >
> > Alex Turner
> >
> > On Apr 6, 2005 3:30 AM, William Yu <wyu@talisys.com> wrote:
> >
> >>Alex Turner wrote:
> >>
> >>>I'm no drive expert, but it seems to me that our write performance is
> >>>excellent.  I think what most are concerned about is OLTP where you
> >>>are doing heavy write _and_ heavy read performance at the same time.
> >>>
> >>>Our system is mostly read during the day, but we do a full system
> >>>update everynight that is all writes, and it's very fast compared to
> >>>the smaller SCSI system we moved off of.  Nearly a 6x spead
> >>>improvement, as fast as 900 rows/sec with a 48 byte record, one row
> >>>per transaction.
> >>
> >>I've started with SATA in a multi-read/multi-write environment. While it
> >>ran pretty good with 1 thread writing, the addition of a 2nd thread
> >>(whether reading or writing) would cause exponential slowdowns.
> >>
> >>I suffered through this for a week and then switched to SCSI. Single
> >>threaded performance was pretty similar but with the advanced command
> >>queueing SCSI has, I was able to do multiple reads/writes simultaneously
> >>with only a small performance hit for each thread.
> >>
> >>Perhaps having a SATA caching raid controller might help this situation.
> >>I don't know. It's pretty hard justifying buying a $$$ 3ware controller
> >>just to test it when you could spend the same money on SCSI and have a
> >>guarantee it'll work good under multi-IO scenarios.
> >>
> >>---------------------------(end of broadcast)---------------------------
> >>TIP 8: explain analyze is your friend
> >>
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>