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/throughputTanel.From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx ] On Behalf Of Matthew ZitoSent: 12 February 2009 19:02 To: jifjif@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx Subject: RE: Oracle Performance on Sunfire T2000We 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
