Re: Oracle Performance on Sunfire T2000

I think the 5220 & 5240 use the T2 chip. As I recall, the T1 chip had limited floating point capability. I think all the virtual CPUs shared the same FPU. I believe the T2 chip relives that particular problem.

As stated in the note, the T1 and T2 chips offer lower single-thread performance, but a lot of multi-thread performance. For some Oracle applications, that works well, but if you have some critical single-thread processes, then you may see much lower performance. Sun offers a CoolThreads test that can run on your current Solaris server to give you an idea of whether your application will run well on a T2 server.

Another issue is how the CPUs are counted. Oracle will usually get that number from the O.S., and Solaris on the T2 chip will tend to return the number of virtual CPUs. Sometimes this can cause you problems. If you create an instance and Oracle thinks there are 128 CPUs, it may allocate more memory than you expect.

Dennis Williams

On Thu, Feb 12, 2009 at 11:51 AM, Pradeep Chetal < Pradeep.Chetal_at_mformation.com> wrote:

>
> Is this also true for T5220/T5240 also?
>
> -- Pradeep
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Allen, Brandon
> Sent: Thursday, February 12, 2009 12:48 PM
> To: oracle-l_at_freelists.org
> Subject: Oracle Performance on Sunfire T2000
>
> 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
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l