Bill
start with looking the DB design - I;ve had batch runs go from 5 days down
to 1/2 day purely by tuning the SQL. I'm not kidding, all the DB tuning
quides say look at the SQL/design first, then look at hardware like
disk/data layout, then finally the CPU.
There's lots of info about tuning on
Bill Moran 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.
> >
On Tue, Apr 25, 2006 at 09:59:20AM -0400, Bill Moran wrote:
> On Tue, 25 Apr 2006 09:48:21 -0400
> Chuck Swiger <[EMAIL PROTECTED]> wrote:
>
> > Bill Moran wrote:
> > [ ... ]
> > >> If you use well optimized applications, you see the larger performance
> > >> gain. Poor optimization causes a CPU
Bill Moran wrote:
On Tue, 25 Apr 2006 09:48:21 -0400
Chuck Swiger <[EMAIL PROTECTED]> wrote:
[ ...long explanation snipped for brevity... :-) ]
Thanks, Chuck.
Most welcome.
What I'm looking for is a way to measure this on the current machines
we're using so I can make a prediction as to whe
On Tue, 25 Apr 2006 09:48:21 -0400
Chuck Swiger <[EMAIL PROTECTED]> wrote:
> Bill Moran wrote:
> [ ... ]
> >> If you use well optimized applications, you see the larger performance
> >> gain. Poor optimization causes a CPU to chug along, flushing the CPU
> >> cache
> >> often, and slowing thin
Bill Moran wrote:
[ ... ]
If you use well optimized applications, you see the larger performance
gain. Poor optimization causes a CPU to chug along, flushing the CPU cache
often, and slowing things down considerably.
I know. That's why I'm so desperately trying to find a way to determine
how
On Tue, 25 Apr 2006 07:59:29 -0500
Derek Ragona <[EMAIL PROTECTED]> wrote:
> 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.
I appreciate your
Bill,
Never assume . . .
Depending on where you got the PostgreSQL, was it in binary form or
source. Most binarys are NOT optimized for higher end, more current
processors, rather they are optimized for the most common family of CPU's.
But if your database application is really CPU bound, I
On Tue, 25 Apr 2006 07:56:03 -0500
Derek Ragona <[EMAIL PROTECTED]> wrote:
> Yes, dual core is on average 20% faster than hyperthreaded CPU's. But that
> is general benchmark. The range of performance difference is 10% - 30%
> depending on the application mix.
Thanks.
> If you use well optim
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
Yes, dual core is on average 20% faster than hyperthreaded CPU's. But that
is general benchmark. The range of performance difference is 10% - 30%
depending on the application mix.
If you use well optimized applications, you see the larger performance
gain. Poor optimization causes a CPU to
On Mon, 24 Apr 2006 18:31:46 -0500
Derek Ragona <[EMAIL PROTECTED]> 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 foll
On Tue, 25 Apr 2006 13:28:50 +0100
"Martin Hepworth" <[EMAIL PROTECTED]> wrote:
> Bill
>
> if the database is CPU dependant I'd look at tuning the queries/indexes and
> that stuff...it really shouldn't be CPU bound.
That's in progress, and it's going to be an ongoing process as the
application go
Bill
if the database is CPU dependant I'd look at tuning the queries/indexes and
that stuff...it really shouldn't be CPU bound.
--
martin
On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote:
>
> On Mon, 24 Apr 2006 23:03:59 +0100
> "Martin Hepworth" <[EMAIL PROTECTED]> wrote:
>
> > Bill
> >
> > dep
On Mon, 24 Apr 2006 23:03:59 +0100
"Martin Hepworth" <[EMAIL PROTECTED]> wrote:
> Bill
>
> depends on the application itself, but more RAM and the disk layout (RAID)
> will be more important than the CPU. Also depends on how write-heavy the
> apps are...
Thanks for the feedback, Martin.
I'm ful
Bill
depends on the application itself, but more RAM and the disk layout (RAID)
will be more important than the CPU. Also depends on how write-heavy the
apps are...
--
martin
On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote:
>
>
> I've been asked to make some hardware recommendations, I'm hoping
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 te
17 matches
Mail list logo