Awesome Scalability of Sun Fire T2000
By pallab on Dec 06, 2005
Awesome Scalability of Sun Fire T2000The UltraSPARC T1 processor with CoolThreads technology is very unique in its kind, has 8 cores, 4 threads per-core and draws power equivalent to a household light bulb. With 32 simultaneous processing threads, it is a breakthrough technology for reducing data center energy consumption without compromising performance or reliability.
Being less power hungry, Sun Fire T2000, with a single UltraSPARC T1 processor, and 4 built-in Gigabit ports, operating at line speed, is ideal for many types of web and edge server applications. The Sun Fire T2000 system comes loaded with Solaris (TM) 10 Operating System and J2SE 1.5 and is suitable for deploying many applications including
- Simple Web server Application with lots of static pages
- Java Servlet/JSP based On line Auctioning Applications
- Java Servlet/JSP based On line Banking Applications
- Java Servlet/JSP based Ecommerce Applications
Any of the application can be taken as-is from current two-way deployment and can be easily deployed as a single instance application on the Sun Fire T2000 system. Unlike several myths from our Competition a Java based application does not need to be re-complied or re-architected for deployment on the new platform, the application class/jar files may well have been created on a x86 based system. Being involved in numerous Early Access customer evaluations, C/C++ based applications running on Lintel based systems get easily ported to SPARC (R)/Solaris (TM). Again unlike the myths, no application code change is necessary.
Do I need to change my Application to run o T2000?
Occasionally what we do see are scaling issues inside the Application itself. These applications were designed for 1 to 2 processor systems and in production there are bunch of these systems in a rack making a web/application/server farm. We are now deploying the application on a T2000 with the same load that was previously applied to the two-way system. Looking at the system vital statistics (mpstat/vmstat/netstat) the customer and myself felt that we can push more load to this single instance of the web application. As we increase the load on the single instance of the application, the hotspots in the application shows up in the system statistics - like mpstat shows high Spin-Mutex-Count or sudden increase in
lpw_mutex\*()function calls. I am fortunate that the Solaris (TM) Operating System is bundled with many tools that can be used to identify hot-spots in customer application. One simple mechanism for Java based Applications is sending a
kill -QUIT < pid_of_jmv >to shows hot monitors used in the application. Others are
plockstatfor hot Solaris (TM) thread locks or the extremely powerful DTrace too to profile an application.
While in the EA program, I have used a Sun Fire T2000 system to highlight hot spots in customer application. Some customers decided to modify the code to get the single instance scaling. This is where the "Changing the Application" story was born and was generalized for "all applications running on the new Chip from Sun"
The sophisticated threading architecture of Sun Java System Web Server 6.1 is highly suitable for Sun Fire T2000. A single instance of the WebServer has demonstrated superb scalability on this system. A 64bit version of the WebServer is scheduled to be released in couple of months. A single instance of this 64bit WebServer can manage Gigabytes of static documents, run a 64bit in-process JVM and manage in excess of 80,000 TCP connections without compromising security or response time.
For Java based applications the following techniques should be investigated to improve performance
- If the application is using an older JVM, try to move the customer
application to the JDK bundled with the OS
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b04)
This has many UltraSPARC T1 specific optimizations.
- If J2SE1.5.0_06 is not an option, try to move the customer application to at least JDK 1.4.2
- If the cusomter application demonstrate pause in seconds due to Garbage
Collection, make sure that the customer is using these JVM flags
'N' can be as small as 2 and a max of 8
J2SE1.5.0_06 also offers
-XX:-UseParallelOldGCto parallelize Old Generation Garbage collection
- Applications configured to use the 64bit JVM and running with Java Heap size
larger than 4GB can use this flag in addition.
There are several other flags, that can be used to scale a single instance up on the Sun Fire T2000 system. A list of JMV Options are listed at this URL
Java based applications deployed on Sun Fire T2000, will often perform much better or atleast similar to the two-way system where they are currently running, without applying any further tunables
Sometimes after ensuring that a single instance can scale to its limit, we find that the Sun Fire T2000 system is not even half utilized. At this point, we use system consolidation techniques - like Run multiple instances of the application, as if consolidating multiple of those two-way systems into a single Sun Fire T2000 system. Depending on the type of the application, a single Sun Fire T2000 system can consolidate anywhere from 3 to 8 two-way systems.
Solaris (TM) 10 provides rich facilities for providing isolation as well as consolidation. If strong isolation is required, one can use a Zone for each two-way system that we consolidate. We take the ip-address of the two-way system and make it the ip-address of the Zone and make the application run in the Zone.
If isolation is not that important, we can still consolidate multiple of those two-way system into a single Sun Fire T2000. Take this example :
How to Consolidate
An existing application farm is addressed by :
The farm has a load balancer that load balances incoming requests into a rack of 16 two-way system with an ip-address in the range of 192.168.1.2 ..... 192.168.1.18
Each of these two-way system runs a Servlet/JSP application in a web container
As a first step, we pick the interface on Sun Fire T2000 that will connect to the load balancer - let it be ipge2
we plumb the ipge2 interface and assign a ip-address to it - 192.168.1.1 we then create 16 logical interfaces and assign the ip-address of each of the two-way system like this:
ifconfig ipge2:1 plumb ifconfig ipge2:1 192.168.1.2 netmask + broadcast + up ... ... ifconfig ipge2:16 plumb ifconfig ipge2:16 192.168.1.17 netmask + broadcast + up
Install a SPARC (R) /Solaris (TM) version of the web container on the Sun Fire T2000. Create 16 instances of the server, (like in case of Tomcat, it is as simple as untarring the Tomcat package in 16 different directories, tomcat1...tomcat16, or use the same binary location for 16 different instances). Each web-application server can be bound to a specific ip-address, configure each of the server to bind to one unique logical interface from the above list, start the servers and we have just consolidated 16 two-way systems in a single Sun Fire T2000 system.
[ Technorati: NiagaraCMT ]