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
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
depends on the
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 goes
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 follow
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
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
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 optimized
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,
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 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
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 things down
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
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 to chug along,
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.
We currently have
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
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
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 fully aware
17 matches
Mail list logo
