Determine CPU usage for applications running in was on z/OS

Determine CPU usage for applications running in WebSphere application Server on z/OS

Brief introduction

The IBM WebSphere application Server environment often hosts several different types of enterprise applications that are supported by different Java EE technologies. These applications often run concurrently, and each consumes system resources, such as CPU cycles and memory, that correspond to the work they perform. It is often useful to view the resources consumed by each application, rather than just the entire application server, during performance testing and production use.

There are a number of tools available to monitor performance statistics within the WebSphere application Server. A basic example is the WebSphere application Server Performance monitoring infrastructure (PMI). It enables you to monitor key areas such as the thread pool and connection pools, which provide indications of which applications are consuming CPU resources, especially when only a very small number of applications are running. However, if you deploy and run many applications on a single server, it can be extremely challenging to pinpoint which applications are consuming system resources.

On z/OS, service Management facility (SMF) and Resource Management Facility (RMF) provide some system tools to help WebSphere application Server System administrators get information about the amount of CPU usage for each application running within the server. Any "problem application" found can then be investigated separately to establish the root cause of the performance problem.

This article applies to Z/OS administrators and explains how to use the z/OS classification rules, SMF, and RMF reports to identify the CPU utilization of each application running in the WebSphere application Server v6.x-v8.5 on z/OS.

Sample Environment

The application described here is a hypothetical application that is intended for demonstration purposes only, and this article does not provide its code. In a real-world environment, the relevant business applications running in the environment will produce performance data for subsequent analysis, and the steps described in this article should apply to these applications.

For the purposes of this article, assume that 4 applications are deployed in the WebSphere application Server on z/OS, and they have different concurrent workloads:

Two of these applications are simple Web applications that run in a Web container.

One is the Enterprise JavaBean (EJB) application.

A message-driven bean (MDB)-based application that uses WebSphere application Server Service integration Bus (SIB).

This environment can be easily extended to include any number of applications you want. Applications in this environment have very limited functionality that consumes CPU cycles only when they are invoked by performing mathematical operations, and we select them to cover 3 major Java EE technology areas.

Classification Rule XML

To isolate different applications to the different report classes that will be displayed in a RMF report, the first step is to create a classification rule XML document. For this example, create an XML document named Zwlm.xml that can have any name to define the classification rules for each application and link those application rules to the transaction class that was subsequently created in the z/OS Workload Manager (WLM). This is shown in Listing 1.

Listing 1. Classification Rule XML Document

<?xml version= "1.0" encoding= "UTF-8"?> <! DOCTYPE classification SYSTEM "CLASSIFICATION.DTD" > <classification schema_version= "1.0" > <!--HTTP
                         Classification Rules--> <inboundclassification type= "http" schema_version= "1.0"
                              default_transaction_class= "Tc_1" >  
As you can see, this document contains 3 subsections, one for a classification rule type: HTTP for Web applications, IIOP for EJB applications, and Jmsra for SIB MDB based applications. The value assigned to the Default_transaction_class field is used as the default value for the work type. For more specific HTTP classification rules, the URI field contains the context root of the deployed WAR. For example, value:
 
Uri= "/migratehelloworldwar/*"
 
To ensure that the transaction class tc_2 is invoked whenever the context root is used, for example:
 
http://myserver.hursley.ibm.com:9080/MigrateHelloWorldWAR/MyServlet?TIME=10000
 
For IIOP (EJB) Classification rules, the application (EAR) name and module name (JAR) must be provided.
 
For SIB MDB applications, the target of SIB name and MDB "Listening" is provided. Typically, each MDB will listen for its own goals. This means it is easy to determine the CPU usage of each application.
 
See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/extra/
 
The complete CLASSIFICATION.DTD associated with the XML is shown in Listing 2.
 
Listing 2. Classification Rule DTD Document
 
<?xml version= ' 1.0 ' encoding= ' UTF-8 '?> ELEMENT Classification (inboundclassification| sibclassification) +> <! Attlist classification schema_version CDATA #REQUIRED > <! ELEMENT inboundclassification ((iiop_classification_info* |http_classification_info*|endpoint*)) > <! Attlist inboundclassification Type (iiop|mdb|http) #REQUIRED > <! Attlist inboundclassification default_transaction_class CDATA #REQUIRED > <! Attlist inboundclassification schema_version CDATA #REQUIRED > <! ELEMENT iiop_classification_info (iiop_classification_info*) > <! Attlist iiop_classification_info activity_workload_classification CDATA #IMPLIED > <! Attlist iiop_classification_info application_name CDATA #IMPLIED > <! Attlist iiop_classification_info component_name CDATA #IMPLIED > <! Attlist iiop_classification_info description CDATA #IMPLIED > <! Attlist iiop_classification_info method_name CDATA #IMPLIED > <! Attlist iiop_classification_info MoDUle_name CDATA #IMPLIED > <! Attlist iiop_classification_info transaction_class CDATA #REQUIRED > <! ELEMENT endpoint (classificationentry*) > <! Attlist endpoint defaultclassification CDATA #REQUIRED > <! ATTLIST endpoint name CDATA #REQUIRED > <! Attlist endpoint Type (messagelistenerport) #REQUIRED > <! Attlist Endpoint Description CDATA #IMPLIED > <! ELEMENT classificationentry empty> <! Attlist classificationentry classification CDATA #REQUIRED > <! Attlist classificationentry selector CDATA #REQUIRED > <! Attlist classificationentry description CDATA #IMPLIED > <! ELEMENT http_classification_info (http_classification_info*) > <! Attlist http_classification_info host CDATA #IMPLIED > <! Attlist http_classification_info Port CDATA #IMPLIED > <! Attlist http_classification_info uri CDATA #IMPLIED > <! Attlist http_classification_info description CDATA #IMPLIED > <! Attlist Http_classification_info Transaction_class CDATA #REQUIRED > <! ELEMENT sibclassification (sib_classification_info+) > <! Attlist sibclassification Type (jmsra|destinationmediation) #REQUIRED > <! Attlist sibclassification default_transaction_class CDATA #REQUIRED > <! Attlist sibclassification schema_version CDATA #REQUIRED > <! ELEMENT Sib_classification_info empty> <! Attlist sib_classification_info transaction_class CDATA #REQUIRED > <! Attlist sib_classification_info selector CDATA #IMPLIED > <! Attlist sib_classification_info bus CDATA #IMPLIED > <! Attlist sib_classification_info destination CDATA #IMPLIED > <! Attlist sib_classification_info discriminator CDATA #IMPLIED > <! Attlist sib_classification_info description CDATA #IMPLIED >