Profiling WebSphere Application Servers with Sun Studio Performance Tools

 
 
By Dileep Kumar, Sun Microsystems
Albert Leigh, Sun Microsystems, January 2007 		 
This article describes how to profile an IBM WebSphere Application Server (WAS) runtime environment with the Sun Studio Performance Analysis Tools, Collector and Analyzer.

To profile IBM WebSphere Application servers, you will need the Sun Studio Performance Tools (e.g. version 11) running on a supported version of the Solaris OS or Linux, including required patches. You will also need a supported version of Java installed. Running the Sun Studio collect command with no argument will run a script that will verify that all the appropriate patches are installed. (See also Profiling Java Applications With Sun Studio Performance Tools , and the Sun Studio 11 Performance Analyzer documentation .)

A server run under IBM WebSphere is written in Java and is launched by running a script that invokes Java Virtual Machine (JVM). To profile a server, you must ensure that the JVM command launching the server is prepended with the collect command with appropriate arguments.  The collect command invokes the Sun Studio Collector. In the discussion below, the shell variable ${COLLECTOR} is used to refer to that command and arguments.

In the first section, we describe how to set ${COLLECTOR} , to the data collection options you will need to use. In the second section, we describe the scripts used to launch a WAS server, and how to edit them to use ${COLLECTOR} . In the third section, we describe navigating through the measured performance data. Finally, in the last section, we provide the web links to the IBM WebSphere documentation.

Data Collection Options

This section describes the setting of ${COLLECTOR} collection options for profiling in WAS startup scripts.

Data Options

The command collect is the first token in the ${COLLECTOR} variable. You may specify it either as an absolute path to wherever you have installed the tools, or as the command name only, provided you have set your path to include the installation location.
The default experiment is a clock-profiling experiment. You may also use hardware counter profiling or synchronization tracing. The experiment begins when the server is launched, and terminates when the server exits. If the profiling session is longer than about 20 minutes, low-resolution profiling should be used to avoid high volumes of data.
Since WAS servers are Java-based, the " -j on" option to collect is always needed.

Experiment Naming and Storage

You can simplify the management of experiments by being careful at naming output files and storing them. You may name experiments with a -o argument specifying a file name including the name of the server, followed by " .1.er ". The first experiment will have the number 1, and subsequent ones should be named with consecutive incremental numbers. You can also use the -d argument to specify a directory into which the experiments should be stored. It should be a locally-mounted, as opposed to NFS-mounted, file system.
You may want to use the date command to generate a string representing the current date and time and embed that string in the experiment name.

Signal Controls

You may use the -y <signal> option for collect to control when data is recorded during the session, and minimize the volume of collected data. You may start the experiment with data collection paused (thus not profiling the server during its startup), and send the signal to resume data collection either just before or shortly after applying a benchmark load to the server. You would send the same signal to pause data collection either shortly before or just after the benchmark load is terminated. You may repeat the resume/pause sequence for other loads, and terminate the server after all is done.
To profile server initialization, you would use "-y <signal>,r" , send the signal after initialization, and then send it again before and after a load is applied, as above.
If data volume is not a problem, but you will be running multiple loads in a single session, you may pass the "-l <signal>" option to collect , and send the signal to insert sample markers after initialization and then after each benchmark load is applied.
When using either of the technique, you should disable periodic sampling by using the "-S off" option to collect . Since WebSphere does not interfere SIGPROF, you can use it to generate samples or to toggle pause/resume, but not both. Such use does not interfere with SIGPROF usage for clock-profiling. You can use a second signal, SIGUSR1, for example, if you want to both control pause and resume and to insert sample markers in the experiment.

Descendant Process Controls

As WAS Servers usually do not spawn additional processes, the command option "-F on" is not needed. If the server you are profiling does create additional processes that you wish to profile, you should enable -F to profile them, either for all descendants or selectively based on the name or lineage of the descendant of interest.

Archiving Controls

Depending on the environment under which you are profiling WAS Servers, you may examine the data on the machine on which it was recorded. If you want to examine it on a different machine, you should set "-A copy" to make the experiment more portable.

Initiating Data Collection

This section describes how you can modify the scripts used to launch WAS servers to enable data collection.

Launching the Servers with Collector/Analyzer

A WAS server process is simply launched by explicitly invoking the " startServer.sh server name" script from the WAS installation bin directory of the WAS profile under which this server has been created. For example,
     startServer.sh server1

where server1 is the name of the server.
To start WAS with Sun Studio Collector/Analyzer tool, we need to start server with " collect -j on " option so that data collection can be enabled.` The following steps describe the necessary procedure to create a copy of the startServer script and modify it to include the collect command:
  1. Go to the $PROFILE_DIR/bin directory.
  2. Generate a copy of the WAS start-up script so that we can modify it to include the " collect -j on " option.  You can name this script arbitarily.  In our example, we name it start-collector.sh . 
                         
startServer.sh  
                    
server_name  
                    
-script  
                    
                       
start-collector.sh
  3. This will create a script named start-collector.sh . We will modify the script to point to the location of the Sun Studio Collector/Analyzer binary and start the Java process with " collect -j on ".
  4. Edit the script to include the Sun Studio bin directory in the PATH settings.  In the example below, the Sun Studio installation directory is located in /java/devtools/sparc/SUNWspro/SS11 .
    • PATH=$PATH:/java/devtools/sparc/SUNWspro/SS11/bin
    • You can put this PATH setting either before or after  " . $binDir/setupCmdLine.sh " line.
  5. Then, replace " exec " in the script with " collect -j on " as shown below. This step demonstrates the WAS V6.1 startup script (the next Step demonstrates the WAS V6.0.x startup script). 
                         
exec "/opt/IBM-startup/WebSphere/AppServer/java/bin/java"
    will become 
                         
collect -j on "/opt/IBM-startup/WebSphere/AppServer/java/bin/java"
  6. In the WAS v6.0.X startup script, there is no exec preceding the java command. Therefore, just prepend " collect -j on " to the last line where the Java command is launched.

  7. Example (WAS v6.0.X):

                         
"$JAVA_HOME"/bin/java $X_ARGS $WAS_DEBZUG $CONSOLE_ENCODING $D_ARGS -classpath "$WAS_CLASSPATH" ....

    will become

                         
collect -j on "$JAVA_HOME"/bin/java $X_ARGS $WAS_DEBZUG $CONSOLE_ENCODING $D_ARGS -classpath "$WAS_CLASSPATH" ....
  8. Save and quit the editor.
  9. The server is now ready to be run with collector .

The data will be collected in the directory from where you will invoke the start-collector.sh script.

You can invoke this script from anywhere as it does not have any relative path info. To force it to collect data in particular directory you may want to use "-d" option in the script where -d directory specifies the experiment directory.

An example a modified script with the collect command can be found in the file start-collector.sh listed below.

More information about the collect and analyze can be found in collect.1 man page.

Note that the script uses -d64, and is intended for use with at 64-bit JVM. The -d64 option should not appear when used with a 32-bit JVM. 

#!/bin/sh
            


# start-collector.sh
            


# Generated: Mon Aug 21 14:54:18 PDT 2006
            


             


# Append the PATH to have the location of Sun Studio Collector/Analyzer
            


PATH=$PATH:/java/devtools/sparc/SUNWspro/SS11/bin
            


             


# Bootstrap values ...
            


binDir=/data2/washome/WebSphere/AppServer/profiles/AppSrv01/bin
            


. $binDir/setupCmdLine.sh
            


             


# For debugging the server process:
            


# export DEBUG="-Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"
            


             


# Environment Settings
            


PLATFORM=`/bin/uname`
            


case $PLATFORM in
            


  AIX)
            


    EXTSHM=ON
            


    D_ARGS=""$D_ARGS" $DELIM -Dibm.websphere.preload.classes=true"
            


    LIBPATH="$WAS_LIBPATH":$LIBPATH
            


    export LIBPATH EXTSHM ;;
            


  Linux)
            


    LD_LIBRARY_PATH="$WAS_LIBPATH":$LD_LIBRARY_PATH
            


    D_ARGS=""$D_ARGS" $DELIM -Dibm.websphere.preload.classes=true"
            


    export LD_LIBRARY_PATH ;;
            


  SunOS)
            


    LD_LIBRARY_PATH="$WAS_LIBPATH":$LD_LIBRARY_PATH
            


    D_ARGS=""$D_ARGS" $DELIM -Dibm.websphere.preload.classes=true"
            


    export LD_LIBRARY_PATH ;;
            


  HP-UX)
            


    SHLIB_PATH="$WAS_LIBPATH":$SHLIB_PATH
            


    D_ARGS=""$D_ARGS" $DELIM -Dibm.websphere.preload.classes=true"
            


    export SHLIB_PATH ;;
            


  OS/390)
            


    PATH="$PATH":$binDir
            


    export PATH
            


    D_ARGS=""$D_ARGS" $DELIM -Dfile.encoding=ISO8859-1 $DELIM -Djava.ext.dirs="$JAVA_EXT_DIRS""
            


    D_ARGS=""$D_ARGS" $DELIM -Dwas.serverstart.cell="$WAS_CELL""
            


    D_ARGS=""$D_ARGS" $DELIM -Dwas.serverstart.node="$WAS_NODE""
            


    D_ARGS=""$D_ARGS" $DELIM -Dwas.serverstart.server="$1""
            


    X_ARGS="-Xnoargsconversion" ;;
            


esac
            


             


             


             


# Launch Command
            


collect -j on "/data2/washome/WebSphere/AppServer/java/bin/java"  $DEBUG "-d64" \
"-XX:MaxPermSize=256m" "-Declipse.security" \
"-Dosgi.install.area=/data2/washome/WebSphere/AppServer" \
"-Dosgi.configuration.area=/data2/washome/WebSphere/AppServer/profiles/AppSrv01/configuration" \
 "-Djava.awt.headless=true" \
"-Xbootclasspath/p:/data2/washome/WebSphere/AppServer/java/jre/lib/ext/ibmorb.jar:\
/data2/washome/WebSphere/AppServer/java/jre/lib/ext/ibmext.jar" \
"-classpath" \
"/data2/washome/WebSphere/AppServer/profiles/AppSrv01/properties:\
/data2/washome/WebSphere/AppServer/properties:/data2/washome/WebSphere/AppServer/lib/startup.jar:\
/data2/washome/WebSphere/AppServer/lib/bootstrap.jar:/data2/washome/WebSphere/AppServer/lib/j2ee.jar:\
/data2/washome/WebSphere/AppServer/lib/lmproxy.jar:/data2/washome/WebSphere/AppServer/lib/urlprotocols.jar:\
/data2/washome/WebSphere/AppServer/deploytool/itp/batchboot.jar:\
/data2/washome/WebSphere/AppServer/deploytool/itp/batch2.jar:\
/data2/washome/WebSphere/AppServer/java/lib/tools.jar" \
"-Dibm.websphere.internalClassAccessMode=allow"\
"-Xms2800m" "-Xmx2800m" \
"-Dws.ext.dirs=/data2/washome/WebSphere/AppServer/java/lib:\
/data2/washome/WebSphere/AppServer/profiles/AppSrv01/classes:\
/data2/washome/WebSphere/AppServer/classes:/data2/washome/WebSphere/AppServer/lib:\
/data2/washome/WebSphere/AppServer/installedChannels:/data2/washome/WebSphere/AppServer/lib/ext:\
/data2/washome/WebSphere/AppServer/web/help:\
/data2/washome/WebSphere/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime" \
"-Dderby.system.home=/data2/washome/WebSphere/AppServer/derby" \
"-Dcom.ibm.itp.location=/data2/washome/WebSphere/AppServer/bin" \
"-Djava.util.logging.configureByServer=true" \
"-Duser.install.root=/data2/washome/WebSphere/AppServer/profiles/AppSrv01" \
"-Djavax.management.builder.initial=com.ibm.ws.management.PlatformMBeanServerBuilder" \
"-Dwas.install.root=/data2/washome/WebSphere/AppServer" \
"-Dpython.cachedir=/data2/washome/WebSphere/AppServer/profiles/AppSrv01/temp/cachedir" \
"-Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager" \
"-Dserver.root=/data2/washome/WebSphere/AppServer/profiles/AppSrv01" "-Xmn1200m" \
"-XX:+AggressiveHeap" "-XX:+UseParallelGC" "-XX:ParallelGCThreads=2" \
"-XX:MaxTenuringThreshold=3" "-XX:LargePageSizeInBytes=2m" "-XX:SurvivorRatio=20" \
"-XX:+UseParallelOldGC" "-Dcom.ibm.ws.pm.batch=true" "-Dcom.ibm.ws.pm.deferredcreate=true" \
"-Dcom.ibm.CORBA.FragmentSize=3000" "-Dcom.ibm.ws.pm.useLegacyCache=false" \
"-Dcom.ibm.ws.pm.grouppartialupdate=true" \
"-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl" \
"-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl" \
"-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl"\
 "-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XML11Configuration" \
"-Djava.security.auth.login.config=/data2/washome/WebSphere/AppServer/profiles/AppSrv01/properties/wsjaas.conf" \
"-Djava.security.policy=/data2/washome/WebSphere/AppServer/profiles/AppSrv01/properties/server.policy" \
 "com.ibm.wsspi.bootstrap.WSPreLauncher" "-nosplash" "-application" \
"com.ibm.ws.bootstrap.WSLauncher" "com.ibm.ws.runtime.WsServer" \
"/data2/washome/WebSphere/AppServer/profiles/AppSrv01/config" \
"wsx12Node01Cell" "wsx12Node01" "server1"

Server Profiles

This section describes tips for examining the server profiles. Unless your server has created additional descendant processes which are profiled and single run creates a single experiment, no experiment filtering of selectivity is needed.

If you have used either of the signal mechanisms described above, you may use sample filtering in the Analyzer or er_print to examine the profile for only part of the run. For example, you may want to look at the startup only, or you may want to look at the data for the individual benchmark loads that were run.

When looking at the Timeline in Analyzer, you may want to color methods from the WAS infrastructure all one color, and use other colors to look at specific sections of your code. You can also show or hide clock profile events that are not CPU-time (that is, they are system CPU-time, or any of the wait states).

WAS Documentation

Sun Studio Documentation

Rate and Review
Tell us what you think of the content of this page.
Excellent   Good   Fair   Poor  
Comments: