Purchasing the correct hardware: dual-core intel? Big cache?
derek at computinginnovations.com
Tue Apr 25 13:00:00 UTC 2006
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.
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
> > 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
> > >
> > >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.
>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
>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.
More information about the freebsd-questions