Recently, an Oracle-L discussion on Sun T2000 servers got me thinking. The T2000 servers have Sun’s new line of processors, UltraSPARC-T1. These processors come with 8 physical cores, and each core has 4 threads (similar to hyperthreading in Intel Xeon Processors). So each UltraSPARC-T1 processor shows up as 32 Processors (8 cores * 4 threads) at the operating system (OS) level. Sun termed this technology “Cool Threads”. It is supposed to give high-volume throughput along with saving millions on power and cooling costs.
But many discussion forums have more complaints against these T2000 servers than praises. As outlined in metalink note 781763.1 – Migration from UltraSPARC I,-V to UltraSPARC T1 and T2 results in 2/3 performance reduction, Most of the performance issues people see are due to the application not being parallel enough. As each Oracle process is going to get just 1/4th time of each core, operations that run in single thread suffer a lot. The quick fix should be to use Oracle Parallel Servers. This can be achieved by setting parallel hint in the SQL query or using
alter table parallel degree clause on the table. Oracle Standard Edition customers are out of luck here, as standard edition doesn’t allow parallel SQL.
Another issue widely discussed on the forums is RMAN performance on T2000 servers. Many people observed that RMAN with compressed backup sets runs much longer than RMAN with non-compressed backup sets. This performance problem is caused by one Floating Point Unit (FPU) being shared by all 8 cores on the T1 processor. This issue is fixed in Sun’s UltraSPARC-T2 processor where there is one FPU per core. So Customer who are using T1 processors can see better performance with compression off in RMAN.
So the question is where does these server fit the best? The answer is web servers — especially web servers that run Java-related technology. Web servers like Apache that spawn lot of threads internally greatly benefit from these servers and “Cool Threads”. Also any application server that is based on J2EE will also able to take advantage of this Cool threads feature, as JVMs that empower these J2EE apps use lot of Threads internally. Oracle products that match this profile are:
- Oracle 11i Ebusiness suite Middle Tier, Runs Apache + Jserv & Pro*C based Concurrent Managers
- Oracle R12 Ebusiness Suite Middle Tier, Runs Apache + OC4J Java containers & Pro*C based Concurrent Managers
- Oracle 10g Application Server Middle Tier, Runs Apache + OC4J containers
Note the Middle Tier phrase in my product description, which means that only the Application Server components. Concurrent Managers which are part of R12 and 11i Apps are also should be OK running on T2000 Servers, as most of these program do their job in the DB using plsql. But ASCP Programs like Memory based 64-bit Planner might see some performance degradation which runs mostly in the Middle Tier memory.
I couldnt agree more with this post. While working for a certain Internet Company, I had the opportunity to lab test a loaner T2000 from Sun in the hopes that we could replace our database servers with these.
Database performance results were disappointing to say the least and we ended canning the hardware migration project and going with commodity hardware..(read DELL)
Thanks Kim for posting your experience here
CMT boxes are optimized for throughput and response time is less for some applications. We generally find that customers are happy with OLTP style environments where transactions tend to have low response times. If your transaction increases from 0.01 seconds to 0.03 seconds, who really cares when the SLA is for < 1 second.
People generally stumble with the utilities like RMAN, import, index builds ect… There are lots of ways to address these types of issues.
I have a lot of information regarding Oracle running on CMT on my blog. Also, there was a joint session with Oracle and myself at OOW 2008 which discussed Oracle running on CMT.