Last updated on JULY 01, 2016
Applies to:Oracle SuperCluster T5-8 Half Rack - Version All Versions and later
Oracle SuperCluster T5-8 Full Rack - Version All Versions and later
SPARC T5-2 - Version All Versions and later
SPARC T5-4 - Version All Versions and later
SPARC T4-1 - Version All Versions and later
Oracle Solaris on SPARC (64-bit)
Sun Solaris SPARC (64-bit)
Oracle Server Enterprise Edition - Version: 184.108.40.206 and beyond
You are upgrading, porting, or consolidating applications and databases from older technology to newer and suffer from performance problems as a result. You incorrectly conclude that this is due to porting to SPARC T4 or T5 processor architecture (SPARC S3 core) and unnecessarily decide to use some other platform. This document is intended as an aid to understand the issues from a hardware perspective, and to provide information and references to assist in resolving cases of this nature.
Question: Why is there a perceived issue with porting to SPARC T4 and T5 based systems?
Answer: UltraSPARC T1 and T2 processors (S1 and S2 cores, respectively)introduced the Chip Multi-Threading (CMT) concept and were initially designed and intended for use in highly paralleled throughput computing rather than for single-threaded performance. During the time such servers were being installed and made available most applications were not optimized for parallel multi-threaded computing. This resulted in many service requests and much speculation, and even several white papers. Oracle Development has made many optimizations in both hardware and software since then; however, even on S3-based systems current customers incorrectly arrive at the idea that a perceived performance problem is due to having recently migrated from sun4u to sun4v.
Question: Is there any truth to the rumor that Oracle DB performance is not optimal on current SPARC T4 and T5 based servers?
Answer: None at all. Most often than not, those issues encountered in the past on S1- and S2-based server systems were due to directly porting a database or binary application from sun4u to sun4v without making any changes to optimize, add parallelism to, or recompile the application code. With the introduction of new compilers, software enhancements and the S3-based server products, there is no longer any reason to consider sun4v architecture as 'The Root Cause' of a any single-threaded performance problem.
Ultimately there are many issues that can affect performance after migration. Once obvious pathologies have been eliminated, such as FMA faults or error messages being reported in the hardware or from the operating system, it is recommended to begin with investigating the application as a first step rather than to start off suspecting the new platform.
This issue typically comes up in any service request where you are porting from sun4u to sun4v, and sometimes in LDOMs/virtualized environments as well.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms