GiAPA OBJECTIVES

  Back to Top 

OTHER BENEFITS

With no (more) performance problems, what are the benefits of (still) using GiAPA?

To analyze performance of all jobs and tasks running on the server, GiAPA obviously collects a lot of data - but is never the less only using less than 0.1 % of one CPU, so GiAPA data collection runs normally 24 / 7 !

Therefore, having optimized inefficiently running applications, GiAPA users detected that GiAPA data was a true gold mine of information

  Back to Top 

EASE OF USE

DATA COLLECTED

GiAPA collects for all jobs every 15 seconds:

Additional Information for HotSpot Jobs
 

(HotSpot = Job exceeds 6 % CPU – user may adjust limit)

·        Call stack down to active statement number

·        Detailed statistics for all opened files

(To our knowledge GiAPA is the only tool collecting file usage data down to individual record number within the file - - - you probably can't imagine how much optimization potential we find by analyzing this data!)

  Back to Top 

RESOURCES USED

GiAPA Performance Data Collection:

Uses typically less than 0.1 % of one CPU and extremely few I/Os when collecting data for all jobs and tasks every 15 seconds. Usage could increase if limit for collecting additional "HotSpot" data is set much lower than the default values.

Expansion and Analysis:

Runs predominantly CPU bound as a low priority batch job, and is in most cases a matter of a few minutes. Processing 10 million collected job/interval performance data records took on a P05 model 270 only 6 minutes elapsed and 5 minutes CPU.

GiAPA Reports:

Most reports run interactively and appear within a second or two. If *ALL details are kept during analysis, a few reports running on this detailed data may take more than a minute; such reports can be submitted to batch.

Graphics:

The different charts are normally created within a second or two - they are displayed in the browser on your PC or MAC, but are produced by program code stored on the server.

How Can Data Be Collected Using < 0.1 % of One CPU?

Reason 1:

I/Os are typically responsible for between 60 and 85 % of the CPU used on a server running commercial applications. GiAPA stores the data collected in a compressed binary format, and builds large blocks of data to keep I/Os down to an absolute minimum.
 

Reason 2:

The performance data (= use of resources) for all jobs are always calculated by the operating system anyway. This already available data is passed to GiAPA in memory every 15 seconds without causing any I/Os.
 

Reason 3:

GiAPA processes the performance data real-time, immediately detecting job(s) using sufficient resources to potentially cause performance problems. GiAPA collects additional "HotSpot" information about programs and files used for these particular jobs. This data is also being received in memory work areas not needing any I/Os.
 

  Back to Top 

GIAPA REPORTING

In addition to below list, there are numerous graphics available
(pie, bar, column, area and line charts) - generated automatically or user defined
 

  Back to Top 

LOOP TRAP

Since information about all resources used by all jobs and tasks is received every 15 seconds during performance data collection, GiAPA can detect if a job starts looping.

If the LOOPTRAP function is activated when data collection is started, GiAPA will send an informational message with severity level 60 to the system operator message queue if a job seems to be looping.

The message is sent if no data base reads are made during xxx minutes, and the CPU usage in the same time period exceeds yyy %, where xxx and yyy are user defined limits.

An exception list is available for job names that never should be reported by the loop trapper

  Back to Top 

DATA SECURITY

For retrieving performance data GiAPA only uses IBM standard APIs and commands. Customer programs, data base files, etc. are obviously never modified by GiAPA in any way, but only accessed by commands like DSPFD or DSPOBJD (or corresponding APIs) to collect basic information about the objects used by the jobs being analyzed.

Authority Needed to Collect Performance Data

The standard authorization assigned by IBM to some of the APIs accessed is limiting their use rather strictly, for which reason *JOBCTL and *ALLOBJ, *SERVICE or even authority on QSECOFR level may be needed for the user running GiAPA data collection. (Example: The API QPMLPFRD "List Performance Data" is shipped with *PUBLIC authority *EXCLUDE, although it only passes performance data to the caller).

  Back to Top 

COMPETITION

  We never really met any –

                                           - there are several nice tools on the market, but …

• some require someone to look at the problem when it occurs   *)

• some need a special data collection started before the problem occurs   *)

• some only analyze one or two jobs or programs at the time   *)

• some are so heavy to run that data collection should be kept to a minimum   *)

• some give so much information that it is easier to find a needle in a haystack  *)

• some are so complex that it takes an expensive expert to find the answer  *)

*) = Statement not being true for GiAPA

  Back to Top 

F A Q s

What is a HotSpot?

A HotSpot means that the standard GiAPA performance data collection found a job that within an interval  exceeded CPU usage or I/O limits defined by the user when starting the data collection. Each HotSpot will cause GiAPA to collect job call stack and file usage data.

Do HotSpots show all details for a job?

The MAX value line tells the maximum use of a resource within any interval where the job was running during the performance data collection. It is used to show peaks.

  Back to Top