By now, I’m sure that many of you have heard at lest some vague rumbling coming out of our friends at Sun about their UltraSPARC T1 and T2 processors, often referred to by the UltraSPARC T1’s development codename of ‘Niagara’. Those of you who have large investments in Sun and UltraSPARC probably have at least taken them for a test drive with your applications, and if you look like most of Sun’s existing customer base, you’ve probably bought one or more.

For those of you who aren’t familiar with Niagara, this is the latest update to the UltraSPARC line of CPUs for use in volume servers, and it’s intended to be an alternative to volume server CPUs such as Intel’s 5000-sequence Xeon and AMD’s Quad-Core Opteron processors. Sun’s been offering them since 2006 in a variety of different form factors, including blades as well as 1 and 2U servers to meet most physical deployment needs.

True to form, these CPUs work great for applications without massive raw compute needs, and even better with applications that tend to sprawl across traditional large multiprocessor systems with many threads. This is due to Sun’s unique chip-multithreading (CMT) technology, allowing for large numbers of smaller workloads to be distributed and scheduled across power-efficient silicon. It’s not surprising that this works great for Java applications and JVMs.

Unfortunately for some of you, the ideal applications for UltraSPARC T1 and T2 are not at all similar to Splunk. Even though Splunk can spread across and utilize today’s multi-core SMP volume server offerings well, it’s not the only dimension of system architecture that’s needed to offer Splunk performance into the realm of hundreds of gigabytes per day.

The first thing to note is that in order to integrate the high number of cores ( up to 8 ) offered on a single UltraSPARC T1 or T2 processor along with CMT, raw clock rate is reduced for all cores. To make a relative comparison, today’s highest-performance UltraSPARC T2 cores run at up to 1.4ghz. In an 8-core configuration, that’s 11.2Ghz of clockcycle available - compared to a dual processor system using Intel Xeon X5460 CPUs, the T2 processor offers only 44% of the total aggregate clock cycles available in the same amount of rackspace from most other volume server vendors.

Of course, it’s never possible to directly compare clock rates between such different CPUs, but these numbers should provide you with some sense of scale. For an UltraSPARC T1 or T2-based server to provide overall better throughput than a system based on 5000-sequence Xeon it would need to provide dramatically better clock-for-clock performance. With the Splunk workload we don’t see this.

The other dimension that intersects directly with raw clock rate is interrupt handling. In the CMT architecture, interrupts that would have ordinarily gone to a CPU core in a conventional architecture go to a thread. Even though this is intuitive, CMT threads inherently cannot sustain similar interrupt handling rates to a regular CPU core. When large numbers of interrupts are being handled, cache and TLB disruption becomes a major issue. Of course, you could always throw more clock rate at the problem; but it’s not exactly available in the UltraSPARC T1 and T2 architectures. Splunk indexers perform large numbers of small writes and reads to disk throughout normal operation. Even with driver optimizations and interrupt aggregation techniques, I/O intensive operations such as operating a Splunk index simply don’t work as well on Niagara as they do on other platforms.

Conceding these two points nets you, the intrepid Splunk user, with a serious performance deficit compared to systems based on 5000-sequence Xeon or AMD Quad-Core Opteron. In Splunk’s test lab with optimized configurations an UltraSPARC T1-based system tends to index at approximately 15% of the performance we generally expect from a system with two 5000-sequence Xeons, or at about 40gb/day.

Many of us here at Splunk have spent a significant amount of time in the trenches of operational IT; myself included, so we know how standardization can play into your department’s purchasing habits and policies. It’s in that spirit that we understand, realize and support Niagara with Splunk. That said, there are several other options inside the Sun realm that offer greater performance-per-dollar for Splunk indexer applications. I’d like to briefly mention the Fire X4150 and X4450 as excellent indexing platforms for Splunk. They offer a high-performance Splunk experience that can be purchased and supported inside Sun shops, as well as offering unique advantages in terms of rackspace savings that aren’t available from the other volume server vendors. I encourage you to check them out.

May you use the best tool for the job at hand, and happy splunking!

Best - Mark

Just a quick introduction here, and an invitation to watch this space for much more in the future.

I’m Mark Bagley, and I’m Splunk’s lead product manager across our Enterprise and Platform efforts. What that means to you: I’m the guy who helps Splunk take your input on what you’d like to see in the product and makes that input happen with the magic worked by our band of merry developers, especially when it means cool stuff like Windows ports and our high availability features.

I joined Splunk in September of 2007 and have to say it’s great to be here on a team with this much talent and dedication to doing something amazing. I’ll be using this blog to share my thoughts on what we’re doing here at Splunk and some of my favorite technology and business topics.

Of course, if there’s anything on your mind about Splunk, how it scales, or how it runs on your favorite *NIX, Linux, or Windows, feel free to drop me email. I’m all ears!