Performance explorer definitions

The parameters and conditions that determine what data performance explorer collects and how it collects it are configured and stored using performance explorer definitions. This topic explains how to use these definitions and provides a sample illustrating a simple definition.

To collect performance explorer data, you need to tell performance explorer what data to gather. You do this by using the Add Performance Explorer Definition (ADDPEXDFN) command to create a performance explorer definition. After the definition is completed and saved, you are ready to continue to the next task in the cycle of work.

Before creating a new definition, consider what kinds of information you want and the amount of detail you need. The performance explorer provides the following types of data collection:

Statistics type definitions

Identifies applications and IBM^® programs or modules that consume excessive CPU use or that perform a high number of disk I/O operations. Typically, you use the statistical type to identify programs that should be investigated further as potential performance bottlenecks.

• Good for first order analysis of i5/OS^® programs, procedures, and MI complex instructions.

  • Gives number of invocations

  • Gives both inline and cumulative CPU usage in microseconds

  • Gives both inline and cumulative number of synchronous and asynchronous I/O

  • Gives number of calls made

• Works well for short or long runs

• Size of the collected data is fairly small and constant for all runs

• Run time collection overhead of ILE procedures may be a problem due to the frequency of calls. Although run time is degraded, the collected statistics are still accurate because Performance Explorer removes most of the collection overhead from the data.

• Uses combined or separated data areas. The MRGJOB parameter on the ADDPEXDFN command specifies whether all program statistics are accumulated in one data area, or kept separate (for example, one data area for each job).

The statistics can be structured in either a hierarchical or flattened manner.

• A hierarchical structure organizes the statistics into a call tree form in which each node in the tree represents a program procedure run by the job or task.

• A flattened structure organizes the statistics into a simple list of programs or procedures, each with its own set of statistics.

Here is an example of a performance explorer statistics definition called MYSTATS that will show CPU and disk resource usage on a per program or procedure level.

   ADDPEXDFN DFN(MYSTATS) /* The name of the definition. */
   TYPE(*STATS) /* The type of definition */
   JOB(*ALL) /*All Jobs */
   TASKS(*ALL) /*All tasks */
      DTAORG(*FLAT) /* Do not keep track of who calls who */

Profile type definitions

Identifies high-level language (HLL) programs, modules, procedures, and statements that consume excessive CPU utilization based on source program statement numbers.

• Program profile (specify TYPE(*PROFILE) and PRFTYPE(*PGM) on the ADDPEXDFN command)

  • Gives detailed breakdown of where you are spending time within a set of programs within a specific job.

  • Can summarize the data by program, module, procedure, statement, or instruction.

  • Size of collection is fairly small and constant regardless of length of run.

  • Limit of 16 MI programs means that you should use this as a second order analysis tool.

  • Can vary overhead by changing sample interval. An interval of 2 milliseconds seems a good first choice for benchmarks.

  • No restrictions on pane size due to the number of programs specified or the size of the programs specified.

  Here is an example of a performance explorer program profile definition called PGMPROF that will show usage for a particular procedure.

   ADDPEXDFN DFN(PGMPROF) /* The name of the definition. */
   TYPE(*PROFILE) /* The type of definition */
   JOB(*ALL) /*All Jobs */
   PGM((MYLIB/MYPGM MYMODULE MYPROCEDURE)) /* The name of the program to monitor. */
   INTERVAL(1) /* 1-millisecond samples will be taken. */

• Job profile (specify the following on the ADDPEXDFN command: TYPE(*PROFILE) and PRFTYPE(*JOB))

  • Gives detailed breakdown of where you are spending time in the set of jobs or tasks of the collection.

  • Size of collection is relatively small but not constant. The size increases as the length of the run increases.

  • Can profile all jobs and tasks on the system or can narrow the scope of data collected to just a few jobs or tasks of interest.

  • Can vary overhead by changing sample interval. An interval of 2 milliseconds seems a good first choice for benchmarks.

  Here is an example of a performance explorer job profile definition called ALLJOBPROF that will show usage for all your jobs.

   ADDPEXDFN DFN(ALLJOBPROF) /* The name of the definition. */
   TYPE(*PROFILE) /* The type of definition */
   PRFTYPE(*JOB) /* A job profile type will be monitored. */
   JOB(*ALL) /*All Jobs */
   TASKS(*ALL) /*All tasks */
   INTERVAL(1) /* 1-millisecond samples will be taken. */

Trace definitions

Gathers a historical trace of performance activity generated by one or more jobs on the system. The trace type gathers specific information about when and in what order events occurred. The trace type collects detailed reference information about programs, Licensed Internal Code (LIC) tasks, i5/OS job, and object reference information.

• Some common trace events are:

  • Program and procedure calls and returns

  • Storage, for example, allocate and deallocate.

  • Disk I/O, for example, read operations and write operations.

  • Java™ method, for example, entry and exit.

  • Java, for example, object create and garbage collection.

  • Journal, for example, start commit and end commit.

  • Synchronization, for example, mutex lock and unlock or semaphore waits.

  • Communications, for example, TCP, IP, or UDP.

• Longer runs collect more data.

Here is an example of a performance explorer trace definition called DISKTRACE that will show usage for all disk events.

 ADDPEXDFN DFN(DISKTRACE) /* The name of the definition. */
 TYPE(*TRACE) /* The type of definition */
 JOB(*ALL) /*All Jobs */
 TASKS(*ALL) /*All tasks */
 TRCTYPE(*SLTEVT) /* Only selected individual events and machine instructions 
are included in the trace definition */
 SLTEVT(*YES) /* *SLTEVT allows you to specify individual machine instructions 
and events to be specified in addition to the categories of events 
available with the TRCTYPE parameter. */ 
 DSKEVT((*ALL)) /* All disk events are to be traced. */

Here is an example of a performance explorer trace definition called HEAPEVENTS.

 ADDPEXDFN DFN(HEAPEVENTS) /* The name of the definition. */
 TYPE(*TRACE) /* The type of definition */
 JOB(*ALL) /*All Jobs */
 TASK(*ALL) /*All tasks */
 MAXSTG (100000) /*Maximum storage. Set to 100000 because the default of 
10000 KB is often too small for the large number of heap events that can be 
generated when tracing all jobs and all tasks.*/
 TRCTYPE(*HEAP) /* Selects all heap events from the STGEVT 
(storage events) parameter. */

Parent topic:

Related concepts
Performance explorer reports