Re: Oracle Performance on Sunfire T2000

From: Martin Berger <>
Date: Fri, 13 Feb 2009 21:33:45 +0100
Message-Id: <>

it's just about the runqueue (I guess). If the runqueue in your 4 fast CPUs is 'long', you will be happy any of the 'slow' 128 Threads process the task and release the latch.
Of course, if you do not utilize 4 CPUs to the limits, you will not need 128 Threads at all.

But still I'm just telling in pure theory, in Summer I will have my new T2+s and have to prove it. Until then, it's pure theory.


Martin Berger

> There's one more catch with slow single thread execution with high
> parallelism in Oracle. If you migrate from 4 fast CPUs to 128 slow
> threads, you will have much heavier latch contention on busy
> latches. Doing whatever work under protection of a latch will
> probably take longer, thus the latch is held for longer. And instead
> of 3-4 concurrent threads trying to get the latch at the same time
> you'll potentially have few hundred ones....
> Glenn Fawcett has quite a few useful blog entries about Oracle
> performance on Sun CMT processors
> Tanel.
> From: [
> ] On Behalf Of Matthew Zito
> Sent: 12 February 2009 19:02
> To:;
> Subject: RE: Oracle Performance on Sunfire T2000
> We have a couple of t1000s, and while our workload is a little odd
> (we're an automation company, so all our several hundred databases
> do is get installed, patched, upgraded, uninstalled, etc.), anything
> involving data dictionary activities (running catupgd.sql, etc. -
> high-cpu single threaded activities) is slower on the t1000s than
> our ancient v210s.
> Supposedly the t1000/2000 are perfect for J2EE apps - lots of
> threads, not a lot of heavy-lifting, parallelization of execution is
> the most critical piece.
> Thanks,
> Matt
> --
> Matthew Zito
> Chief Scientist
> GridApp Systems
> P: 646-452-4090

  • application/pkcs7-signature attachment: smime.p7s
Received on Fri Feb 13 2009 - 14:33:45 CST

Original text of this message