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 -----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: http://blogs.sun.com/glennf/tags/cmt http://blogs.sun.com/mandalika/entry/running_batch_workloads_on_sun regards, Jeff Wong 2009/2/13 Bobak, Mark <Mark.Bobak@xxxxxxxxxxxx> Brandon, 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 -- Mark J. Bobak Senior Database Administrator, System & Product Technologies ProQuest 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> www.proquest.com <http://www.proquest.com> www.csa.com <http://www.csa.com> 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.