Oracle don’t include this in the marketing material – SPARC T series servers have dismal single thread performance

I don’t do new years resolutions. But having said that, I am going to blog more this year. In my day job I do a lot of research, and much of the time months later, the information is forgotten/not recorded/in a black hole. Or if I am lucky I have written it down or stored a bookmark somewhere. So without further ado, todays post is about making you aware that you need to be careful migrating legacy Solaris workloads to the T-series family of servers. This is especially relevant today, maybe more than ever before in the age of virtualisation and clouds. During my day job, at least once or twice a year I come across a situation that could have been avoided – a poorly written or poorly tuned application placed on an Oracle Sparc T-series server.

A Brief History

In 2002 Sun Microsystems invested in a company called Afara Websystems that was developing an innovative highly multi threaded processor tuned for highly multi-threaded applications. The name of this processor was called Niagra, and they had some ex-Sun employees in their company. The idea was to build a platform which would run Java and the web screaming FAST, and being able to process large numbers of execution threads simultaneously. In conventional processors, the most latency during execution is when data has to be fetched from main memory. With a large number of hardware threads the thread requesting main memory can be idled while the request to main memory is in progress – and the core can execute another ready to run hardware thread. Building the T-series platform was about re-thinking the way processors had evolved up until that point and stripping the layers back to the basics to reduce latency during instruction execution. Web traffic generally matches this multi-theaded profile that is suitable for T-series hardware. Java can be – or not, depending on which developer you have writing your code. Java application servers can match this profile as well – as long as you don’t have lock contention, then all bets are off and your application slows to a crawl – but more of that later. Just remember, more often than not – a legacy java app server has not been written with optimised multi-threading in mind. Thats been my experience anyway.

Without going into too much detail – the T1 processor as it was later called, was:

optimised for speed by keeping each core’s instruction pipeline as busy as possible.

does not perform out of order execution of instructions.

the T1 consisted of a single processor, with up to 8 cores.

the T1 runs at speeds up to 1.4Ghz.

each core has 4 threads per core, giving a maximum concurrency of 32 threads.

Came in 4 variants, 1, 2 or 4 physical processors running at 1.65Ghz (almost no change from the T2)

Up to 512GB memory depending on the T3 server model

Across the first three generations, the chip did not change much. Mostly incremental changes, a few more cores, a few more chips, some extra buses, but nothing spectacular.

One thing that is constant across them all, is extremely poor single thread performance. I cannot stress this enough!! Oracle don’t include this in the marketing material. A combination of a slow clock speed, coupled with no L3 cache, no out of order execution of instructions, and poorly written/tuned applications makes for pretty dismal performance. These poorly tuned applications run perfectly fine on the circa 2004-2006 SPARC IV/IV+ line of processors that power the multiprocessor V480, V490, V880, V890, and the E25k platforms! Your single threaded app runs perfectly fine on a SunFire V890 but when migrated to a new and shiny T3-4 it runs like a dog. Sometimes up to 10x slower, you probably won’t be impressed. But even more frustrating is that someone in the business has just spent a significant investment on newer hardware with an expectation of better performance. On a T5220 (T2 based) the litmus test was to check CPU utilisation while your workload was running. If it was running at a constant 3.125% utilisation and not going any higher, chances are you had a single thread problem. This indicates that a single hardware thread is running at 100% (1/32 *100).

Effectively what this means is that if a core detects it is executing a single thread – then all resources that would be used to handle other threads, are directed to help that single thread execute as fast as possible.

The T4 is the first T-series platform that you can do serious application consolidation from legacy hardware. Using Oracle virtual machines (OVM) for SPARC (previously known as LDOMs) gives you the flexibility to carve up a T4-4 (4 processors) to place legacy workloads. As all T-series chips only support Solaris 10 (and now Solaris 11), if you want to consolidate Solaris 8 or 9 workloads you need branded zones within an OVM.

Conclusion

The underlying architecture of the T-series from inception has not changed much over about 7 years. I have seen customers consolidate existing workloads onto these platforms in the last few years where they saw many unexpected performance problems. Mostly they have been resolved by optimising database queries, or re-architecting applications to work more efficiently under the T-series multi-thread model. With the T4 and upcoming T5 – things should improve and sites that have large legacy Sun/Solaris footprints will be able to finally consolidate – without having to spend a bomb on M-series servers. Most of the time you want to consolidate and get power saving benefits – the T4 processor or higher fits the bill. The T5 is expected to bring back 16 cores per chip as per the T3 architecture but with the T4 single thread speed improvements.

2 thoughts on “Oracle don’t include this in the marketing material – SPARC T series servers have dismal single thread performance”

I always felt that the T Series mostly solved a problem that no longer exists. It was an amazing feat of engineering to get an E10K’s worth of web server performance onto a 1U box with the original. Unfortunately (for Sun) few organisations have that much web serving to do (and selling a $2500 box to do the job of a $1M one isn’t great business). The T series hasn’t been great at handling other workloads – especially anything that needs an FPU. Perhaps that’s starting to change, but Intel’s relentless tick-tocking to make Moore’s Law stay true is hard to keep up with.

Sorry for late reply. ;-)
Yeah totally agree – at the time of design there was a need. But by the time they came to market, things had moved on. Also, T4’s will probably be discontinued when the T5’s come out. Short sales periods (a little over 12 months) causes potential issues with IT roadmaps/strategy, eg: if you want to augment a RAC cluster for example and cannot buy a T4 based server anymore.