Oracle Performance on Sunfire T2000

From: Allen, Brandon <Brandon.Allen_at_OneNeck.com>
Date: Thu, 12 Feb 2009 10:47:38 -0700
Message-ID: <64BAF54438380142A0BF94A23224A31E111A40C519_at_ONEWS06.oneneck.corp>



Hi List,

Just curious if any of you have had major performance problems on the T2000? We just migrated a JDE on Oracle 10g environment from an old V440 to a new T2000 and it's horribly slow. After doing some research, I found some other reports of similar problems, but no real solutions as it seems to come down to a limitation of the hardware - apparently this UltraSPARC T1 processor with "Chip Multithreading Technology" was designed to do lots of little separate operations concurrently, but it doesn't do so well with large, single-threaded tasks such as large full table or index scans, JDE batch jobs, imp/exp, gzip/gunzip, grep on a large file, etc. This is a 1 chip, 8 core processor, multi-threaded into 4 threads per core, so it presents itself to Oracle as having 32 (virtual) CPUs. When we run anything CPU intensive, the most it can get is 1/32 of the total processing power (3.1% in top), and this just isn't enough to get anything done in an acceptable time, for example, below  is a quick test I ran on the T2000 and then on a Dell 2950 for comparison - you can see the Dell did ~20K buffer gets in .34 seconds of cpu time while the T2000 took 3.22 seconds to do the same amount of work.

Has anyone else found a magic parameter to help with this problem? One of the tech support guys we talked to from Sun said that Oracle offers some special version that is designed to work better on this architecture, but I'm skeptical of that claim and haven't been able to find any details or evidence yet. We're still following up with both Sun and Oracle support though. We were also considering trying to disable (via psradm) all but one of the virtual processors per core in an attempt to disable the multi-threading and present Oracle with just 8 more powerful processors instead of 32 weaker processors, but from our research so far, it seems that won't work as we'd hoped and will instead just leave us with 25% of the total processing power.

If you're reading this and you are considering purchasing migrating to a T2000, I recommend you test your application/database performance thoroughly on this platform before committing to it. Luckily I think Sun offers a "try before you buy" program.

Thanks,
Brandon

Dell 2950:


select * from t1

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse        1      0.00       0.00          0          1          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch    17478      0.33       0.56          0      20182          0      262144

------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 17480 0.34 0.56 0 20183 0 262144

T2000:


select * from t1

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch    17478      3.22       3.08          0      20115          0      262144

------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 17480 3.22 3.08 0 20115 0 262144 ********************************************************************************

Test Script:

SQL> create table t1 as select * from dba_objects where rownum < 2;

Table created.

SQL> insert into t1 select * from t1;

1 row created.

SQL> / 2 rows created.

SQL> / 4 rows created.

SQL> / 8 rows created.

SQL> / 16 rows created.

SQL> / 32 rows created.

SQL> / 64 rows created.

SQL> / 128 rows created.

SQL> / 256 rows created.

SQL> / 512 rows created.

SQL> / 1024 rows created.

SQL> / 2048 rows created.

SQL> / 4096 rows created.

SQL> / 8192 rows created.

SQL> / 16384 rows created.

SQL> / 32768 rows created.

SQL> / 65536 rows created.

SQL> / 131072 rows created.

SQL> exec dbms_monitor.session_trace_enable();

PL/SQL procedure successfully completed.

SQL> set term off
SQL> _at_t1
SQL> quit

-bash-3.00$ cat t1.sql

select * from t1;

Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.
--

http://www.freelists.org/webpage/oracle-l Received on Thu Feb 12 2009 - 11:47:38 CST

Original text of this message