Suveen Nadipalli's Web Log

Sun Java System Application Server Performance Tunings On UltraSPARC T1 Chip Multithreading Systems

I want to share sun application server's tunings information on UltraSPARC T1 systems for best possible performance.

Application Server Software Versions :

Sun Java System Application Server 8.2
If you are using application server 8.1 then Patch 119167-02 with Java SE 1.5.0_06 is necessary.

The UltraSPARC T1 processor combines chip multiprocessing (CMP) and hardware multithreading (MT) with an efficient instruction pipeline to enable chip multithreading (CMT). The resulting processor design provides multiple physical instruction execution pipelines and several active thread contexts per pipeline. The UltraSPARC T1 processor was designed to scale well with applications that are throughput oriented and multi threaded in nature, so this is an ideal platform for application servers.

Following are the list of tunings :

Use of FX scheduling class:

It is recommend to put the application server into the FX scheduling class. To do so, find out the process id of the appserver process (ps -ef | grep appserv) and MQ Broker daemon (ps -ef | grep mqbrokerd). For each process id, execute: /usr/bin/priocntl -s -c FX -m 59 -p 59 -i pid process_id_of_appserver.

Disk Configuration:

If your application logs HTTP access requests or are using XA transactions or MDBs, then you will want to follow these guidelines for the disk:

1. Separate the access logs, transaction logs and imq files onto as many disks as possible. If you have two disks, put the XA transaction logs (instance_directory/logs/tx) on one disk and the imq files (instance_directory/imq/instances/imqbroker/fs350) on another. If you have more disks, put the imqbroker txn file on its own disk.
2. If you run with multiple instances of the application server, move the logs of each instance onto separate disks as much as possible.
3. Mount the disk with these options: nologging,directio,noatime.

Network Configuration:

If you are using more than one network interface, then you will need to make sure that all the network interrupts are not going to the same core.

Java VM Tunings :

A number of optimizations have been added to the newly released J2SE 5.0_06 for CMT and for UltraSPARC T1 processors in particular. Also if you find that your application doesn't scale well, try running it with JDK 1.5.0_06 with the -XX:+UseBiasedLocking option, which can help improve the performance of applications with significant amounts of uncontended locking.

Placing Java Heap on Large Pages:

LargePageSizeInBytes requires J2SE 5.0_06 and Solaris 10 HW2. Also when you are setting the heap size make sure that it is a multiple of the large page size.

-XX:LargePageSizeInBytes=256m
-Xmx2560m -Xms2560m

Reduce the default thread stack size:
The default thread stack size can be changed using the -Xss option. Selecting a value such as 256k or 512k will reduce the amount of virtual memory reserved for each Java thread's stack.
-Xss128k

Tune GC Threads:
When running your application, you might need to scale back the number of garbage collection (GC) threads. This obviously depends heavily on the amount of garbage being generated. Too many GC threads can affect the throughput of the system. A good starting point is to set the number of GC threads to the number of cores on the system running UltraSPARC T1 processors.

XX:ParallelGCThreads=N
where "N" is the number of cores

Other JVM tunings:
-server
If appropriate for your environment, disable the security manager by removing the -Djava.security.policy argument from the jvm-options
-XX:+AggressiveHeap

Application Server Specific Tunings :

Thread pools : You want to size the HTTP thread pool as small as possible while still getting good throughput. you also want to size the HTTP acceptor threads to match the machine. Having one acceptor-thread per core is optimal. Even for ORB thread pool, you want to size it as small as possible.

JSP recompilation: turn this off (either in the application's web.xml or in application server instance's default-web.xml)

Change the application server log level to WARNING.

Disable dynamic reloading and autodeploy features.

Turn the access logging off.

Posted at 03:03PM Feb 08, 2006 by suveen in Sun  |  Comments[2]