Oracle Performance on Sunfire T2000
- From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 12 Feb 2009 10:47:38 -0700
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> @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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
