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

Поиск
Список
Период
Сортировка
От Alex Turner
Тема Re: How to improve db performance with $7K?
Дата
Msg-id 33c6269f05040708464df3909a@mail.gmail.com
обсуждение исходный текст
Ответ на Re: How to improve db performance with $7K?  (Richard_D_Levine@raytheon.com)
Ответы Re: How to improve db performance with $7K?  (Richard_D_Levine@raytheon.com)
Список pgsql-performance
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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: help on explain analyse in psql 7.1.3 (linux)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Building postmaster with Profiling Support WAS "Tweaking a C Function I wrote"