Re: How to improve db performance with $7K? - Mailing list pgsql-performance

From Richard_D_Levine@raytheon.com
Subject Re: How to improve db performance with $7K?
Date
Msg-id OFBBA6D5E0.8FAB98C1-ON05256FDC.005A2CCD-05256FDC.005A7FAA@ftw.us.ray.com
Whole thread Raw
In response to Re: How to improve db performance with $7K?  (Alex Turner <armtuk@gmail.com>)
List pgsql-performance
Yep, that's it, as well as increased quality control.  I found this from
Seagate:

http://www.seagate.com/content/docs/pdf/whitepaper/D2c_More_than_Interface_ATA_vs_SCSI_042003.pdf

With this quote (note that ES stands for Enterprise System and PS stands
for Personal System):

There is significantly more silicon on ES products. The following
comparison comes from a study done in 2000:
· the ES ASIC gate count is more than 2x a PS drive,
· the embedded SRAM space for program code is 2x,
· the permanent flash memory for program code is 2x,
· data SRAM and cache SRAM space is more than 10x.
The complexity of the SCSI/FC interface compared to the
IDE/ATA interface shows up here due in part to the more
complex system architectures in which ES drives find themselves.
ES interfaces support multiple initiators or hosts. The
drive must keep track of separate sets of information for each
host to which it is attached, e.g., maintaining the processor
pointer sets for multiple initiators and tagged commands.
The capability of SCSI/FC to efficiently process commands
and tasks in parallel has also resulted in a higher overhead
“kernel” structure for the firmware. All of these complexities
and an overall richer command set result in the need for a
more expensive PCB to carry the electronics.

Rick

Alex Turner <armtuk@gmail.com> wrote on 04/07/2005 10:46:31 AM:

> Based on the reading I'm doing, and somebody please correct me if I'm
> wrong, it seems that SCSI drives contain an on disk controller that
> has to process the tagged queue.  SATA-I doesn't have this.  This
> additional controller, is basicaly an on board computer that figures
> out the best order in which to process commands.  I believe you are
> also paying for the increased tolerance that generates a better speed.
>  If you compare an 80Gig 7200RPM IDE drive to a WD Raptor 76G 10k RPM
> to a Seagate 10k.6 drive to a Seagate Cheatah 15k drive, each one
> represents a step up in parts and technology, thereby generating a
> cost increase (at least thats what the manufactures tell us).  I know
> if you ever held a 15k drive in your hand, you can notice a
> considerable weight difference between it and a 7200RPM IDE drive.
>
> Alex Turner
> netEconomist
>
> On Apr 7, 2005 11:37 AM, Richard_D_Levine@raytheon.com
> <Richard_D_Levine@raytheon.com> wrote:
> > Another simple question: Why is SCSI more expensive?  After the
> > eleventy-millionth controller is made, it seems like SCSI and SATA are
> > using a controller board and a spinning disk.  Is somebody still making
> > money by licensing SCSI technology?
> >
> > Rick
> >
> > pgsql-performance-owner@postgresql.org wrote on 04/06/2005 11:58:33 PM:
> >
> > > You asked for it!  ;-)
> > >
> > > If you want cheap, get SATA.  If you want fast under
> > > *load* conditions, get SCSI.  Everything else at this
> > > time is marketing hype, either intentional or learned.
> > > Ignoring dollars, expect to see SCSI beat SATA by 40%.
> > >
> > >      * * * What I tell you three times is true * * *
> > >
> > > Also, compare the warranty you get with any SATA
> > > drive with any SCSI drive.  Yes, you still have some
> > > change leftover to buy more SATA drives when they
> > > fail, but... it fundamentally comes down to some
> > > actual implementation and not what is printed on
> > > the cardboard box.  Disk systems are bound by the
> > > rules of queueing theory.  You can hit the sales rep
> > > over the head with your queueing theory book.
> > >
> > > Ultra320 SCSI is king of the hill for high concurrency
> > > databases.  If you're only streaming or serving files,
> > > save some money and get a bunch of SATA drives.
> > > But if you're reading/writing all over the disk, the
> > > simple first-come-first-serve SATA heuristic will
> > > hose your performance under load conditions.
> > >
> > > Next year, they will *try* bring out some SATA cards
> > > that improve on first-come-first-serve, but they ain't
> > > here now.  There are a lot of rigged performance tests
> > > out there...  Maybe by the time they fix the queueing
> > > problems, serial Attached SCSI (a/k/a SAS) will be out.
> > > Looks like Ultra320 is the end of the line for parallel
> > > SCSI, as Ultra640 SCSI (a/k/a SPI-5) is dead in the
> > > water.
> > >
> > > Ultra320 SCSI.
> > > Ultra320 SCSI.
> > > Ultra320 SCSI.
> > >
> > > Serial Attached SCSI.
> > > Serial Attached SCSI.
> > > Serial Attached SCSI.
> > >
> > > For future trends, see:
> > > http://www.incits.org/archive/2003/in031163/in031163.htm
> > >
> > >     douglas
> > >
> > > p.s. For extra credit, try comparing SATA and SCSI drives
> > > when they're 90% full.
> > >
> > > On Apr 6, 2005, at 8:32 PM, Alex Turner wrote:
> > >
> > > > I guess I'm setting myself up here, and I'm really not being
ignorant,
> > > > but can someone explain exactly how is SCSI is supposed to better
than
> > > > SATA?
> > > >
> > > > Both systems use drives with platters.  Each drive can physically
only
> > > > read one thing at a time.
> > > >
> > > > SATA gives each drive it's own channel, but you have to share in
SCSI.
> > > >  A SATA controller typicaly can do 3Gb/sec (384MB/sec) per drive,
but
> > > > SCSI can only do 320MB/sec across the entire array.
> > > >
> > > > What am I missing here?
> > > >
> > > > Alex Turner
> > > > netEconomist
> > >
> > >
> > > ---------------------------(end of
broadcast)---------------------------
> > > TIP 9: the planner will ignore your desire to choose an index scan if
> > your
> > >       joining column's datatypes do not match
> >
> >

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Any way to speed this up?
Next
From: "Joel Fradkin"
Date:
Subject: Re: Any way to speed this up?