Typical data needed for WebSphere performance analysis on Solaris

To analyze the performance of WebSphere (App Server, Portal Server, Process Server, ESB, Commerce Server, etc.) applications on Solaris, we obviously need to get some baseline and collect data. Are you just doing a performance benchmark? Are you doing a tuning exercise? Or, are you in more critical situation where your production server is not performing to the required service level agreement (SLA)? To examine any performance issue, you must know the symptom. A description like "this Solaris server is slow" is not sufficient. You must have some idea how the system is behaving - e.g. whether it is related to high or low CPU utilization, memory usage, Java exceptions, etc.

There is an IBM document that describes potential issue categorized by "components" as described in "MustGather: Read first for all WebSphere Application Server products". We also have documented the things you can do to gather data and perform trouble shooting in our "IBM Redbook: WebSphere Application Server v6.1 on Solaris 10" (Chapter 10).

The summary from these documents is as follows [WAS v6.1 or newer will have the new Java commands -- jmap, jinfo, jstat, etc.]:

Solaris Data

Collect the baseline system configuration information.

cat /etc/release
cat /etc/system
prtdiag
df -k
ifconfig -a
zoneadm list -cv
ndd get ... [See this blog entry for detail]

Then, during a load condition and when the issue occurs, collect the following system data samples.

mpstat 10 10
vmstat 10 10
intrstat 10 10
prstat -mLc
ps -efZ
/usr/ucb/ps -auxwww | grep -i <keywords: WebSphere java>
<WAS_HOME>/java/bin/jinfo <WAS_PID>
<WAS_HOME>/java/bin/jmap -heap <WAS_PID>
plockstat <WAS_PID>   [Wait for a few minutes then hit <Control-c>]
kill -3 <WAS_PID>  [Take 3-4 times a couple of minutes apart]

WAS and Java Data

<WAS_HOME>/java/bin/java -version
<WAS_HOME>/bin/versionInfo.sh

...collect the following files (sample paths that need to be 
   modified for your environment)...
<WAS_PROFILE>/<AppServer>/config/cells/<Cell>/nodes/<node>/servers/server1/server.xml
<WAS_PROFILE>/<AppServer>/config/cells/<Cell>/resources.xml
<WAS_PROFILE>/<AppServer>/logs/server1/*
The following two commands should also be run during load condition and when the issue occurs:
<WAS_HOME>/java/bin/jmap -heap <WAS_PID>
<WAS_HOME>/java/bin/jstat -gcutil <WAS_PID> 10000 20

The first set of data could be your baseline. What are your performance goals? Is there a performance issue that inhibiting you to accomplish those goals? Then, do analysis, tune, re-run (may require restart or reboot of WAS and Solaris), and this could take some iterations until you iron out the problem. If you need more information about performance management of WAS on Solaris 10, look at Chapters 9 and 10 of the Redbook, our performance presentation at Impact 2008, Dileep Kumar's Blog, and the rest of my blog. If you are relying someone else to do the analysis, these files could be zipped and sent to whom it may concern. Good luck!

Comments:

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

Mostly pertaining to Cloud Computing, Application Infrastructure, Oracle Exastack, Exalogic, Solaris, Java and Sun servers for the enterprise!

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