RE: Oracle Performance on Sunfire T2000

  • From: "Matthew Zito" <mzito@xxxxxxxxxxx>
  • To: <jifjif@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 12 Feb 2009 21:02:14 -0500

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.


Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of ~Jeff~
Sent: Thu 2/12/2009 6:42 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Oracle Performance on Sunfire T2000
Hi all
We've also been benchmarking for a provisioning app on m5000 vs t5120.  While 
the database hasn't been driven particularly hard for this we're still seeing 
some surprising metrics, like "log file sync" taking twice as long on the t5120 
(same configuration on backend SAN).
Curiously the  (multithreaded, non-oracle) app improved performance on the 
t5120 when the LDOM had it's "CPUs" reduced from 8 to 4. We think this might be 
to do with time slices or something, but are still investigating with the Sun 
guys.  This reduced the context switching, and isn't relevant to the RDBMS.
On another project individual response sucked, but aggregate throughput was 
acceptable especially after changing FILESYSTEMIO_OPTIONS to SETALL.
On the whole they can be a great little server, but it's not always a 
plug'n'play proposition - it seems a degree of optimisation is needed:
Jeff Wong
2009/2/13 Bobak, Mark <Mark.Bobak@xxxxxxxxxxxx>



        We went through something very similar.  In our case, we also moved 
from an old V440 to a new server w/ the new "Coolthreads" CPU.  We also ended 
up moving back to the old server.




        Mark J. Bobak
        Senior Database Administrator, System & Product Technologies
        789 E. Eisenhower, Parkway, P.O. Box 1346
        Ann Arbor MI 48106-1346
        +1.734.997.4059  or +1.800.521.0600 x 4059
        mark.bobak@xxxxxxxxxxxx <mailto:mark.bobak@xxxxxxxxxxxxxxx> <> <> 
        ProQuest...Start here. 


        From: oracle-l-bounce@xxxxxxxxxxxxx 
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Allen, Brandon
        Sent: Thursday, February 12, 2009 12:37 PM

        To: oracle-l@xxxxxxxxxxxxx
        Subject: RE: Oracle Performance on Sunfire T2000 


        I just found Metalink note 781763.1 that addresses this exact issue and 
unfortunately the only solution appears to be moving to different hardware.


Other related posts: