Using Sun Studio with WebSphere Application Server


Profiling WebSphere Servers Using Sun Studio Performance Tools


This page describes profiling servers being run under IBM's WebSphere Application Server system with the Sun Studio Performance Tools.

To profile WebSphere Application Server(WAS), you will need to have a release of the Sun Studio Performance Tools, picked from the release list, properly installed and configured.
All uses of the Sun Studio Performance Tools require a supported version of Solaris including any required patches. They also need a supported version of Java installed which can be used from WAS installation, this is bundeled and gets installed with WAS. Running the collect command with no arguments will run a script that will verify that all the appropriate patches are installed.
A server run under IBM's WebSphere is written in Java; (see "Profiling Java Applications"). A server is launched by running a script which invokes the JVM to run it. To profile a server, you must ensure that the JVM command launching the server is prepended with a collect command, with appropriate arguments, to invoke the Sun Studio Collector. In the discussion below, the shell variable ${COLLECTOR} is used to refer to that command and arguments.

In the next section, we describe setting ${COLLECTOR}, that is, determining the data collection options you will want to use. In the following section we describe the scripts used to launch a server, and how to edit them to insert ${COLLECTOR}. In the third section, we describe navigating through the measured performance data. In the last section, we give links to the IBM WebSphere documentation.

Data Collection Options
This section describes the setting of collection options for profiling, that is determining what to use for ${COLLECTOR} in WebSphere startup scripts.

Data Options
The command collect is the first token in the ${COLLECTOR}
variable. You may be 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.
The default experiment is a clock-profiling experiment. You may also use hardware counter profiling or sychronization 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 and storing them. You may name experiments with a -o argument specifying a name including the name of the server, followed by ".1.er". The first experiment will have the number 1, and subsequent ones will get consecutive 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 to 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 are 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 these techniques, you should disable periodic sampling, using the -S off option to collect.
WebSphere does not interfere SIGPROF, so you can use it to generate samples or to toggle pause/resume, or to generate samples, 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
Usually WAS Servers do not spawn additional processes, so -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
WAS servers are simply launched by explicitly invoking the following script from the bin directory of the profile under which this server has been created.
startServer.sh  <server name>
eg. 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.

To do so follow the following steps:

  1. Go to the $PROFILE_DIR/bin dir.
  2. Issues the command:  startServer.sh <server_name> -script <script_name_to_be_used_with_collector>
  3. This will create a script name <script_name_to_be_used_with_collector>
  4. Now the script need to be modified to point to Sun Studio Collector/Analyzer tool binary location and start the java process with "collect -j on"
  5. Edit the script to have the Sun Studio bin dir in the PATH settings
    1. PATH=$PATH:/java/devtools/sparc/SUNWspro/SS11/bin
    2. You can put it either before or after . $binDir/setupCmdLine.sh line.
  6. Then replace "exec" in the script with "collect -j on". Save and quit the editor.
    1. exec "/opt/IBM-startup/WebSphere/AppServer/java/bin/java"
      will become collect -j on
      "/opt/IBM-startup/WebSphere/AppServer/java/bin/java"
    2. This is really a long line.
    3. You may not find exec if you are using 6.0.X based WAS
      installation then in that case you can just append "collect -j on " to
      the last line where the java commnad is launcehd.

  7. The server is now ready to be run with collector.



The data will be collected in the directory from where you will invoke the <script_name_to_be_used_with_collector>
script. You can invoke this script from anywhere as it doesn't have any relative path info.

To force it to collect data in particular directory you mya want to use "-d" option in the script:

-d <directory>        specify experiment directory

An example of such a complex script can be found in the file start-collect.sh

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


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 coloring to look at specific sections of you 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).
This is live document and we will keep on updating this more current updates.

WAS Documentation
Documentation for WAS 6.1 can be found on IBM's web site.
Some topics of interest are:

Comments:

Post a Comment:
Comments are closed for this entry.
About

dkumar

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today