Distributed Monitoring and Application Management

Home > Performance and Tuning > ITCAM for WebSphere Application Server and J2EE V6.1 Data Collector Performance Tuning Guide

ITCAM for WebSphere Application Server and J2EE V6.1 Data Collector Performance Tuning Guide

This topic includes performance tuning information about IBM® Tivoli® Composite Application Manager (ITCAM) for WebSphere® Application Server J2EE V6.1.

Introduction

IBM Tivoli Composite Application Manager (ITCAM) is a family of products allowing a user to monitor J2EE applications running on WebSphere (ITCAM for WebSphere version 6.1) as well as other J2EE application servers, such as WebLogic, JBOSS, Oracle, and so on (ITCAM for J2EE version 6.1). These products provide a customer with capability to monitor mission critical J2EE applications as well as to conduct deep-dive diagnostics of issues found through monitoring.

The Data Collector (DC) monitoring component of ITCAM products is responsible for collecting all transaction and request metrics, Java Virtual Machine metrics, WebSphere PMI metrics and other type of information such as thread and heap dumps. DC consists of platform-independent JAR files and platform-dependent native libraries and it runs within the targeted (monitored) J2EE application server process (java) to collect the metrics. DC sends data to ITCAM Management Server components for data rendering in ITCAM Web Console (or Visualization Engine) and data persistent in Management Server database. Since DC runs within the monitored J2EE application server process, it incurs a certain level of performance overhead to the application server depending on degree of monitoring level and other DC configuration settings.

ITCAM DC offers three monitoring levels for runtime transactions and requests: Monitor on Demand (MOD) level-1, level-2 and level-3. These MOD levels can be dynamically changed using the ITCAM Management Server console in order to give a user flexibility to choose the best suitable balance between level of data volume, depth, and granularity compared with the DC monitoring overhead incurring to provide the data under a particular condition and a user's purpose. ITCAM Management Server also provides a mechanism to control the MOD level automatically based on a user-defined schedule. The detailed descriptions and configurations of the MOD levels and their scheduling mechanism can be found in ITCAM for WebSphere Application Server V6.1 User's Guide.

General recommendation for MOD level-1, level-2, and level-3, and their use cases are documented in the User's Guide, which you can use as a guideline.

These flexible features of the MOD level management allow a user to monitor the production J2EE applications for 24 x 7 continuously with the appropriate level of depth associated with reasonable overhead that is best suited to the user's goal. In addition to these MOD level management, ITCAM DC provides some finetuning to further customize DC's CPU, memory, and throughput behavior. ITCAM DC is configured for best balance between performance and data collection level. However, under a particular user scenario, a user may like to finetune the behavior of DC to optimize the performance and data collection level for a particular purpose. The purpose of this document is to describe these finetune options of ITCAM DC to customize DC behavior in terms of CPU, memory consumption, and data collection capability.

Note that there is no magic to reduce performance in a nearly optimized environment. In most cases, a user must accept the trade-off between performance overhead and the level of monitoring. However, the optimal combination of the trade-off can vary from one user to another. This document addresses the trade-off and presents how a user can finetune ITCAM DC for their environment.

The following table summarizes DC Tuning options discussed in this document, their scope of expected improvements, WebSphere Application Server/J2EE applicability, out of the box default setting, brief description of prescription and potential costs of tuning. A user may refer to Appendix for high level descriptions of ITCAM for WebSphere Application Server/J2EE V6.1 features involved in the tuning options.

Table 1: Tuning Option Summary

Table 2: Tuning Option Summary (continued)

The rest of the document is organized as follows: First an overall DC tuning approach is described in a step-by-step fashion. Next, each tuning option is described in detail - parameters to be changed, expected performance impact, locations and default values of the parameters and step-by-step tuning instruction. Then,
several ITCAM for WebSphere Application Server J2EE DC overhead best practices are described.

Step-By-Step DC Tuning Approach

ITCAM for WebSphere Application Server/J2EE DC includes a set of tuning parameters with default values, which may or may not be suitable to a particular user environment and use scenarios. Conduct the following step-by-step overall DC tuning. Further information for each tuning option can be found in theITCAM Data Collector Tuning Options section.

STEP 1 (apply to WebSphere Application Server only): Disable unnecessary PMI counters (See Section 4.1. for detail)

1. A user must identify which PMI counters are necessary for MOD level-1 monitoring and which counters can be dropped from default PMI configuration (For WebSphere Application Server V6 default is BASIC PMI counter set. For WebSphere Application Server V5.1 default is described in datacollector.properties WebSphere Application Server PMI Section). Appendix-B lists all PMI counters available for WebSphere Application Server V6 and WebSphere Application Server V5 and their monitoring levels, by which you can map to Data Collector MOD level that uses the counters.
2. Disable the unnecessary PMI counters as described in Section 3.1 Fine Grained PMI Counter Option.

STEP 2: DC Internal Buffer Tuning (See Section 4.2. for detail)

1. Determine if there are frequent DC turbo mode engagements logged in trace-dc.log. Frequent DC Turbo engagement may not be desirable as it can slow down response times under L3 and high volume L2 monitoring conditions. Appendix-A of this document contains more detail on DC Turbo behavior.
2. If it is acceptable to have larger DC memory footprint under L3 and high volume L2 monitoring conditions, increase internal.memory.limit value from 100 to 200 or more to reduce a chance of DC Turbo Mode engagement.
3. Another consideration to minimize a chance of DC Turbo engagement is to upgrade ITCAM Management Server capacity, especially for PS components. Typically DC event flow to MS is limited by the PS processing capacity. You can increase the PS processing capacity by (1) having additional PS process(es) (i.e. less number of DCs that contend against each other per PS) and/or (2) upgrading the CPUs of the machine that the PS processes are running on by increasing the number of CPUs or replacing them with faster CPUs.

STEP 3: Apply MOD level-2 Instrumentation Fine Tuning (See Section 4.3. for detail)

1. Determine if it is acceptable for a user to disabled a subset of instrumentation for MOD L2 nested requests. This can be done per J2EE container level for WebSphere. For J2 platform per EJB method level controls are also available. An example is shown in Section 3.3. MOD L3 Instrumentation Tuning Option of this document.
2. If it is acceptable, disable selected MOD L2 instrumentation as described in Section 3.3 MOD level-2 Instrumentation Tuning Option of this document.

STEP 4: Use MOD L2 Method Profiling (See Section 4.4. for detail)

1. Configure MOD L2 Method Profiling. This consist of (1) configure L3 BCI by uncommenting am.camtoolkit.gpe.customxml.L3 in toolkit_custom.properties (2) uncomment and set com.ibm.tivoli.itcam.toolkit.ai.methodentryexittrace **property to true (3) Configuring DC from Web Console to MOD L2 and check the Method Profiling check box.
2. Increase value of am.mp.leagueTableSize in datacollector.properties to have large enough table entries so that Method Profiling table can contain all methods captured. A user may need to experiment with this value to find out what is the sufficient size of the table.
3. Examine the output of Method Profiling. If a user finds many trivial or uninterested method entries, disable L3 instrumentation points for those methods as described in Section 3.5 MOD L3 Method Filtering Option of this document.
4. Use MOD L2 Method Profiling instead of MOD L3 - this will reduce DC data volume dramatically but in many cases providing more useful information to analyze transaction performance than MOD L3.

STEP 5: Apply MOD L3 Method Filtering Option (See Section 4.5. for detail)

1. Using information from MOD L2 Method profiling, identify trivial or uninterested method names.
2. Filter out those methods from MOD L3 instrumentation as described on Section 3.5 MOD L3 Method Filtering Option of this document.
3. Use MOD L2 Method Profiling instead of MOD L3 if applicable.

STEP 6: Confirm that GPE Turbo Option is ON (See Section 4.6. for detail)

1. GPE Turbo should be always on. Confirm that am.camtoolkit.gpe.turbomode=true in toolkit.properties file.

STEP 7: Disable DC when no monitor is needed (See Section 4.7. for detail)

1. Disable DC from Web Console when no monitor is needed. This will minimize performance overhead and ability to turn on DC on-line when needed.

ITCAM Data Collector Tuning Options

In the following section each of tuning options will be discussed in the following order:

1. Name of configuration parameter
2. Expected impact of tuning
3. File(s) containing the configuration parameter(s)
4. Default
5. Instruction

All tuning options are readily available with ITCAM for WebSphere Application Server V6.1 (FixPack-1) Data Collector installation.

Fine Grained PMI Counter Option

1. Name of configuration parameter: am.pmi.settings.nochange
   
   
2. Expected impact of tuning: Enabling/Disabling some PMI counters directly impact WebSphere Application Server CPU overhead and throughput performance. Total PMI overhead can be up to 5-6% depending on application behavior. Especially reducing/disabling bean counter may have a large improvement (2-3%) if the application uses many EJBs. If a user is not interested in some PMI counters in MOD level-1, they can be turned off automatically when MOD level-1 is set. Similarly PMI counters in MOD level-2 and level-3 can be fine tuned.
   
   
3. File contains the File(s) containing the configuration parameter(s):
   <DCHOME>/datacollector.properties
   
   
4. Default: am.pmi.settings.nochange=false
   
   
5. Instruction:
   
   
   1. Use the default setting am.pmi.settings.nochange=false.
      
      
   2. (For WebSphere Application Server V6) Add am.was6custompmi.settings.1 parameter to define specific PMI Counters to be enabled with MOD level-1. A detail description of this parameter is found in datacollector.properties file. Similarly, add am.was6custompmi.settings.2 and am.was6custompmi.settings.3 parameters for MOD level-2 and level-3 PMI counters.
      
      
   3. (For WebSphere Application Server V5) Use am.was5pmi.setting.1, am.was5pmi.setting.2 and am_.was5pmi.setting.3_ instead as documented in the datacollector.properties file. Appendix-B lists all PMI counters available for WebSphere Application Server V6 and WebSphere Application Server V5 and their monitoring levels, by which you can map to Data Collector MOD level that uses the counters.
      
      
   4. Restart the Application Server (PMI setting will be dynamic after the first restart).

DC Internal Buffer Tuning Option

1. Name of configuration parameter: internal.memory.limit
   
   
2. Expected impact of tuning parameter: DC Turbo Mode is a data collection mechanism that ensures integrity and successful storage of event data, improves event dequeueing speed, and improves throughput of requests through the application server in the event that the DC's internal buffers become filled. Please see Appendix-A of this document and ITCAM for WAS/J2EE Turbo Mode Guide for detail descriptions. Frequent DC Turbo engagement may not be desirable as it may slow down response times under L3 and high volume L2 monitoring conditions. If this is the case, a user can reduce the probability of DC Turbo Engagement by increasing internal buffer size defined by internal.memory.limit parameter.
   
   
3. File(s) containing the configuration parameter(s):
   <DCHOME>/datacollector.properties
   
   
4. Default: internal.memory.limit=100
   
   
5. Instruction:
   
   
   1. Determine if there are frequent DC turbo mode engagements logged in trace-dc.log. A user may also notice occasional pauses of Application Server transactions as indicators of DC Turbo engagement. It is very unlikely for DC Turbo to engage at MOD L1. Usually it engages at L3 with deep tracing or high volume L2 monitoring conditions.
      
      
   2. If it is acceptable to have larger DC memory overhead instead of frequent DC turbo mode engagements under L3 and high volume L2 monitoring conditions, increase internal.memory.limit to a larger value, such as 200.
      
      
   3. Restart the Application Server.
      
      
   4. This will reduce the chance of DC turbo mode engagement. However, it will increase peak memory overhead under high volume DC events by 100MB (or higher).
      
      
   5. It is reported that multiple DCs may send bursts of events to the MS simultaneously after the MS is recovering from off-line state. In that case, the larger DC event buffer might exaggerate the size of the bursts.
      
      
   6. Another consideration to minimize a chance of DC turbo mode engagement is to upgrade ITCAM Management Server capacity, especially for PS components. Typically DC event flow to MS is limited by the PS processing capacity. We can increase the PS processing capacity by (1) having additional PS process(es) (i.e. less number of DCs that contend against each other per PS) and/or (2) upgrade CPUs of the machine the PS processes are running on by increasing number of CPUs or replacing them with faster CPUs. Instruction to configure additional PS procesces is found in Chapter 10 of ITCAM: Managing Server Installation and Customization Guide (GC32-1931-00) or http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.itcamwas.doc_6.1/rev/ms_ws_full130.htm and http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.itcamwas.doc_6.1/rev/ms_ws\_full130.htm.
      
      
   7. A user should reduce number of DC events for MOD L2 and L3 monitoring by applying tuning options in Sections 3.3, 3.4 and 3.5. These will help reducing overhead by both (1) reducing instrumentation points and (2) reducing DC turbo mode engagement.

MOD Level-2 Instrumentation Tuning Option

1. Name of configuration parameter: See in prescription.
   
   
2. Expected impact of tuning: Excluding unnecessary L2 instrumentation will reduce L2 performance overhead in terms of CPU and throughput. Instrumentation for L2 nested requests can be easily disabled on a selective base. For WebSphere, instrumentation can be disabled per container basis. For J2 platforms, classes can be filtered out from EJB instrumentation.
   
   
3. File(s) containing the configuration parameter(s): No parameters by default. They can be added to <DCHOME>/runtime/<server-name>/custom/toolkit_custom.properties.
   
   
4. Default: No level-2 instrumentation exclusion.
   
   
5. Instruction:
   
   
   1. For selected instrumentations to be disabled, set the corresponding properties in toolkit_custom.properties to a value of 'false':
      • com.ibm.tivoli.itcam.toolkit.ai.enableejb=false # disables EJB instrumentation
      • com.ibm.tivoli.itcam.toolkit.ai.enablejca=false # disables JCA instrumentation
      • com.ibm.tivoli.itcam.toolkit.ai.enablejdbc=false # disables JDBC instrumentation
      • com.ibm.tivoli.itcam.toolkit.ai.enablejndi=false # disables JNDI instrumentation
      • com.ibm.tivoli.itcam.toolkit.ai.enablejms=false # disables JMS instrumentation
      • com.ibm.tivoli.itcam.toolkit.ai.enableservlet=false # disables servlet instrumentation
      • com.ibm.tivoli.itcam.toolkit.ai.enablesessioncount=false # disables HTTP Session counting instrumentation
      • com.ibm.tivoli.itcam.dc.ctg.enablectg=false # disables CTG instrumentation
        
        
   2. Restart the Application Server to disable the instrumentations.

J2 Only: On J2EE servers, normally all EJB business methods are instrumented for EJB request data. It's possible to filter out classes from EJB instrumentation and reduce the cost of L1 and L2 data collection. Here is an example of how this can be done. In this case, the customer want to exclude EJB classes from instrumentation from a package called 'sample.package'.

The customer needs to create an XML file in the DCHOME/runtime/<server-name>/custom directory. In this example, he creates a file called excludeEJB.xml, containing the following:

<?xml version="1.0"?>

<gpe>
  <bci>

  <weaveFilters>       

 <selectClass>
     <selectionId>EntityBean</selectionId>
     <Matches>!sample.package.\*</Matches>
 </selectClass>

 <selectClass>
     <selectionId>SessionBean</selectionId>
     <Matches>!sample.package.\*</Matches>
 </selectClass>

 <selectClass>
     <selectionId>MessageDrivenBean</selectionId>
     <Matches>!sample.package.\*</Matches>
 </selectClass>

  </weaveFilters>
 </bci>
</gpe>

The presence of the '!' in front of "sample.package.*" on the <Matches> tag indicates that classes beginning with these prefixes should be excluded from Entity Bean, Session Bean, or Message Driven Bean instrumentation. After creating the XML file, the user should then modify the toolkit_custom.properties file to add a reference to the XML file. The user should add a property that begins with the prefix am.camtoolkit.gpe.customxml, followed by a suffix to make it unique. The value of the property should be the file name of the XML file in order to identify the XML file.
For example:

am.camtoolkit.gpe.customxml..excludeEJB=excludeEJB.xml.

MOD Level-2 Method Profiling Option

1. Name of configuration parameter: Method Profiling check box in MOD level-2 configuration page in Web Console.
   
   
2. Expected impact of tuning: Use MOD L2 Method Profiling instead of MOD L3 when it is sufficient. MOD L2 Method profiling provides method entry/exit data but only as aggregated data per method whereas L3 provide instance data. This will dramatically reduce volume of data generated by DC and thus reduce CPU and memory overhead and the chance of DC event buffer overflow.
   
   
3. File(s) containing the configuration parameter(s): Method Profiling check box in MOD level-2 configuration page in Web Console.
   
   
4. Default: disabled
   
   
5. Instruction:
   
   
6. Configure L3 BCI by uncommenting am.camtoolkit.gpe.customxml.L3 in <DCHOME>/runtime/<server-name>/custom/toolkit_custom.properties.
   
   
   1. Uncomment and set com.ibm.tivoli.itcam.toolkit.ai.methodentryexittrace **property in <DCHOME>/runtime/<server-name>/custom/toolkit_custom.properties to true.
      
      
   2. Restart the Application Server
      
      
   3. Set MOD L2 and check MOD L2 Method Profiling check mark in the ITCAM MS Adminstrator Console ADMINISTRATIONMONITORING ON DEMAND.
      
      
   4. Use MOD L2 with Method Profiling instead of MOD L3 when aggregated method entry/exit data is sufficient
      
      
   5. In <DCHOME>/runtime/<server-name>/<server-name>.datacollector.properties file, there are a few parameters to fine tune Method Profiling behavior. Important ones are:
      
      
      • # Support for Method Profiling
      • am.mp.cpuThreshold=30
      • am.mp.clockThreshold=30
      • am.mp.leagueTableSize=10000

am.mp.cpu.Threshold (in nanoseconds) and am.mp.clock.Threashold (in milliseconds) specify minimum CPU and clock times for a method to get measured. Method profiling allocates a fixed size table at startup time, in which it saves its method statistics. The size of this table is given by the am.mp.leagueTableSize property. The default is 10000, but a user might find that this value is too small. A user may need to experiment with this value to find out what is the sufficient size of the table. If it is too small, Method Profiling output will not display all methods captured. If a user increases the size of this property, application server needs to be restarted.

MOD Level-3 Method Filtering Option

1. Name of configuration parameter: method_entry_exit.xml file
   
   
2. Expected impact of tuning: Excluding unnecessary classes/methods from L3 method instrumentation by controlling Byte Code Injection will reduce L3 performance overhead in terms of CPU and throughput. DC configuration in Management Server Web Console also can exclude methods dynamically without having to restart server but this static definition of BCI exclusion is better in performance.
   
   In most cases, level-3 monitoring generates a large number of method entry/exit data from a small set of classes/methods - sometimes from just 2 or 3 methods. Also it is typical that the most of these methods have trivial response times and thus less investigative value for transaction performance analysis. Proper tuning of L3 instrumentation requires that unimportant or trivial methods should not be instrumented or reported on. However, often, it's difficult to determine which classes and methods should be filtered out.
   
   You can use Method Profiling feature described in Section 3.4 of this document to help spotting those classes or methods that should be filtered out. By enabling Method Profiling, and then analyzing the resulting data, you can quickly determine which methods are either of no interest or run so briefly and so often that collecting detailed data is unnecessary. Once these methods are filtered out, L3 tracing will consume less overhead, and the reports will be easier to read and provide more value to the customer.
   
   Also consider using L3 Filter Generation Tool developed by ITCAM ACE team (available on CAM Wiki page), which allows the user to construct an XML filter for monitoring methods based on existing data in the ITCAM for WebSphere database. This helps significantly with overhead at Level 3.
   
   
3. File(s) containing the configuration parameter(s): <DCHOME>/itcamdc/etc/method_entry_exit.xml
   
   
4. Default: No custom method exclusion.
   
   
5. Instruction:
   
   
   1. Uncomment am.camtoolkit.gpe.customxml.L3 in <DCHOME>/runtime/<server-name>/custom/toolkit_custom.properties to enable MOD L3 BCI.
      
      
   2. Uncomment and set com.ibm.tivoli.itcam.toolkit.ai.methodentryexittrace **property in <DCHOME>/runtime/<server-name>/custom/toolkit_custom.properties to true.
      
      
   3. Edit <DCHOME>/itcamdc/etc/method_entry_exit.xml as in the example below to exclude unnecessary classes/methods.
      
      
   4. Restart application server.

Example of custom L3 method filtering: Within the Customer class, we want all methods to be BCI'd for entry/exit. Within the Supplier class, all methods should be BCI'd, except for those methods beginning with 'get' or 'set'.

GPE Turbo Option

1. Name of configuration parameter: am.camtoolkit.gpe.turbomode
   
   
2. Expected impact of tuning: GPE turbo will reduce code path in java BCM logic unnecessary for MOD L1 and MOD L2 monitoring levels, therefore will reduce CPU and throughput overhead of MOD L1 and L2. Note that this option should be true always for performance optimization. We provide this option for a future potential functionality/compatibility and no need to turn it off with ITCAM for WebSphere Application Server/J2EE V6.1.
   
   
3. File(s) containing the configuration parameter(s):
   <DCHOME>/toolkit/etc/toolkit.properties
   
   
4. Default: am.camtoolkit.gpe.turbomode=true
   
   
5. Instruction:
   
   
   1. Confirm that am.camtoolkit.gpe.turbomode=true.
      
      
   2. If it has been set to false, set am.camtoolkit.gpe.turbomode=true and restart the Application Server to configure GPE Turbo option for minimum MOD L1 and L2 overhead.

Disable DC Option

1. Name of configuration parameter: Data collector Configuration in ITCAM Web Console
   
   
2. Expected impact of tuning: Minimize DC overhead to disable DC monitors. This will give them a heart beat and the ability to enable DC when needed.
   
   
3. File(s) containing the configuration parameter(s): This is ITCAM Web Console configuration: ADMINISTRATION --> SERVER MANAGEMENT --> DATA COLLECTOR CONFIGURATION
   
   
4. Default: DC enabled
   
   
5. In ITCAM Web Console: ADMINISTRATION --> SERVER MANAGEMENT --> DATA COLLECTOR CONFIGURATION and select "Disable" button

ITCAM Data Collector Best Practices

• Use MOD Level-2 Method Profiling instead of MOD Level-3. In most cases, the aggregate method entry/exit data is sufficient for transaction performance analysis. Often aggregate data is more powerful to understand nature of performance issues than instance data, yet it offers lower overhead.

• Fine tune MOD L3 filter using Method Profiling data and L3 Filter Generation Tool.

• Do not collect more data than you can effectively analyze. Generating detail data by itself will not help resolving performance problems at all; rather it will induce more performance overhead to your system.

• A good performance analysis is typically done based on a small set of data with some inductive/deductive thinking processes. A flood of data usually just confuses you.

APPENDIX A

This Appendix is a list of high level descriptions of ITCAM for WebSphere Application Server/J2EE V6.1 features involved in the tuning options presented in this document.

DC Turbo Mode

DC Turbo is a data handling algorithm in DC native code controlled by properties in datacollector.properties file. Detail of DC Turbo can be found in ITCAM for WebSphere/J2EE Turbo Mode Guide available on CAM Wiki. Engaging DC turbo will change DC data handling logic in native codes. It will increase DC data throughput to Management Server component by (1) raising the priority of native event agents and network agents and (2) lowering the sleep times of native event agents and network agents when native DC event buffer size grows over a threshold specified by turbo.mem.ulimit (default is 75% of internal.memory.limit specified in Megabytes (MB) with a default value of 100). When DC event buffer size goes down to a level specified by turbo.mem.llimit (default is 60% of internal.memory.limit specified in MB with a default value of 100) it goes back to normal mode. It will also reduce incoming data by turn off all instrumentation of newly arriving transactions during Turbo Mode. This will ensure that no DC event data will be dropped but may negatively impact J2EE transactions/requests throughput during DC turbo mode as DC network and event agents take higher priority and CPU time is taken away from J2EE transaction/request threads. The throughput may be partially compensated by disabling instrumentation for newly arriving transactions. Also note that enabling DC turbo configuration by itself should not affect performance if Turbo mode does not engage.

Method Profiling

Method Profiling is an optional feature of MOD L2 monitoring available in MOD L2 configuration screen. **MOD L2 Method profiling provides method entry/exit data but only as aggregated data per method whereas L3 provide instance data. This will dramatically reduce volume of data generated by DC and thus reduce CPU and memory overhead and the chance of DC event buffer overflow.

AspectJ and Weaving

AspectJ is Byte Code Instrumentation (BCI) technology adopted by ITCAM for WebSphere Application Server/J2EE V6.1 data collector and weaving is an AspectJ terminology for bytecode instrumentation.

GPE Turbo

GPE turbo will reduce code path in java BCM logic unnecessary for MOD L1 and MOD L2 monitoring levels, therefore will reduce CPU and throughput overhead of MOD L1 and L2. Note that this option should be true always for performance optimization. We provide this option for a future potential functionality/compatibility and no need to turn it off with ITCAM for WebSphere Application Server/J2EE V6.1.

APPENDIX B

Enabling WebSphere Application Server V6.x Performance Monitoring Infrastructure(PMI)

WebSphere Application Server V6 PMI data is organized according to B (Basic), E(Extended), A (All). By default DC Monitoring levels are configured according to the following PMI levels. At L1 - Basic, L2 - Extended, L3 - All. So the following table describes which counters are displayed at what level.

If you enable the Extended set, apply & save, then go to Custom set, you can add LocalCommittedCount to the set of enabled metrics and won't need to enable All.

WebSphere Application Server V5 PMI Counters

WebSphere Application Server V5 PMI metrics are organized according to NONE, LOW, MEDIUM, HIGH, XTREME. At each DC monitoring level, we have certain PMI level in effect by default. At L1- PMI level is at (M) MEDIUM, L2 - (H) HIGH, L3 - (X) XTREME. The following tables describe which metrics are displayed at what levels.

BeanModule data counters

Data counter definitions

JDBC connection pool data counters

Data counter definitions

PMI collects performance data for 4.0 and 5.0 JDBC data sources. For a 4.0 data source, the data source name is used. For a 5.0 data source, the JNDI name is used.

J2C connection pool data counters

Data counter definitions

Java Virtual Machine data counters

Data counter definitions

Object Request Broker data counters

Data counter definitions

Session data counters

Data counter definitions

Transaction data counters

Data counter definitions

ThreadPool data counters

Data counter definitions

Web application data counters

Data counter definitions

Workload Management data counters

Data counter definitions

System data counters

Data counter definitions

Dynamic cache data counters

Data counter definitions

Web Service Gateway (WSGW) data counters

Data counter definitions

Please read the copyright and notices statement for this information.