Purchasing the correct hardware: dual-core intel? Big cache?

[Derek Ragona]

If your database application is CPU bound, you may need to re-architect the 
database.  You may need more indexes.  You may be calculating values on 
queries, rather than storing calculated values.

There are many ways to optimize a RDBMS performance, but the first thing to 
do is analyze the data model, and how the data is used.

         -Derek


At 07:47 AM 4/25/2006, Bill Moran wrote:
>On Mon, 24 Apr 2006 18:31:46 -0500
>Derek Ragona <derek at computinginnovations.com> wrote:
>
> > You can get better information directly from intel's website on
> > motherboards and CPU performance.  Dual core is faster than hyperthreaded
> > CPU's usually about 20% if you use the larger CPU cache models.
>
>I don't follow you here.  Are you saying that dual core is about
>20% faster than hyperthreaded with larger cache?
>
> > However with a RDBMS as the primary usage, I would look for more ways to
> > optimize the system.  I would look to use a RAID array with an add-on card
> > (or zero-chanel add-on) as this will provide better performance (with a
> > raid 0) or better performance with redundancy (raid 10, or RAID 0+1.)  A
> > RAID adapter will offload the DISK I/O providing substantially better
> > performance.
>
>We are using Dell PERC controllers with SCSI 320 disks in a RAID-10
>configuration, and battery-backed cache.  As a result, disk IO is _not_
>a bottleneck.  All of our tests up till now have demonstrated that
>memory and disk usage are minimal, and that CPU usage is the current
>bottleneck.
>
> > At 02:46 PM 4/24/2006, you wrote:
> >
> > >I've been asked to make some hardware recommendations, I'm hoping some
> > >folks on the list can make some suggestions.
> > >
> > >We're looking hard at getting either Intel dual-core procs, or getting
> > >hyperthreaded procs with huge (8M) caches.
> > >
> > >We currently have a few dual proc Intel HT machines that we can test
> > >out our workload on, and I'm trying to get a feel for how to determine
> > >if a larger cache size will generate better performance than replacing
> > >HT procs with full-blown dual-core procs.  We're looking at the 6850
> > >from Dell, which supports both processor families:
> > >http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850 
> ?c=us&cs=555&l=en&s=biz
> > >
> > >The goal for these machines is to serve out PosgreSQL databases to as
> > >many Apache+php front ends as we can hang off each one.  So we're trying
> > >to purchase hardware that will create a DB server that can handle a lot
> > >of web server front ends.
> > >
> > >I have a Dell 2850 (dual HT procs) here that I can use for testing.
> > >I'm a little fuzzy on determining how well the cache is working, so I'm
> > >stuck on whether or not the 8M cache that's available on the HT units
> > >is worth the money or not.  Can anyone suggest a testing methodology
> > >that will isolate this particular aspect?
> > >
> > >--
> > >Bill Moran
> > >Collaborative Fusion Inc.
> > >_______________________________________________
> > >freebsd-questions at freebsd.org mailing list
> > >http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > >To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe at freebsd.org"
> > >
> > >--
> > >This message has been scanned for viruses and
> > >dangerous content by MailScanner, and is
> > >believed to be clean.
> > >MailScanner thanks transtec Computers for their support.
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> > MailScanner thanks transtec Computers for their support.
> >
> >
>
>
>--
>Bill Moran
>Collaborative Fusion Inc.
>
>****************************************************************
>IMPORTANT: This message contains confidential information and is
>intended only for the individual named. If the reader of this
>message is not an intended recipient (or the individual
>responsible for the delivery of this message to an intended
>recipient), please be advised that any re-use, dissemination,
>distribution or copying of this message is prohibited. Please
>notify the sender immediately by e-mail if you have received
>this e-mail by mistake and delete this e-mail from your system.
>E-mail transmission cannot be guaranteed to be secure or
>error-free as information could be intercepted, corrupted, lost,
>destroyed, arrive late or incomplete, or contain viruses. The
>sender therefore does not accept liability for any errors or
>omissions in the contents of this message, which arise as a
>result of e-mail transmission.
>****************************************************************
>_______________________________________________
>freebsd-questions at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>MailScanner thanks transtec Computers for their support.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.