Re: Oracle Performance on Sunfire T2000

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. 

br
 Martin

--
Martin Berger    http://berxblog.blogspot.com
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 http://blogs.sun.com/glennf/tags/throughput 

Tanel.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx ] On Behalf Of Matthew Zito 
Sent: 12 February 2009 19:02
To: jifjif@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
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
mzito@xxxxxxxxxxx
http://www.gridapp.com

Other related posts: