IBM Tivoli Monitoring: Implementation and Performance Optimization for Large Scale Environments

Chapter 5. Optimizing performance within an IBM Tivoli Monitoring environment 179

number of attribute groups have been designated for historical collection

multiplied by the data collection interval.

After a PDS becomes full, the automatic maintenance process begins. A check is

made to see if there are any empty PDSs remaining to continue data collection. If

no empty data sets remain, then data collection is temporarily suspended while

maintenance is applied to the oldest data set.

The maintenance job will either back up the PDS to another location (such as

DASD or tape), or it will export the data into a flat file suitable for external

programs to post process the data. The maintenance job carries a large

overhead and if started will slow the entire historical collection process down.

We recommend that application of the maintenance jobs should be minimized.

For most users, the Tivoli Data Warehouse via the warehouse proxy agent

should be used as the backup procedure, rather than archiving onto tape or

DASD with a recommended warehousing occurring every 24 hours.

If the maintenance job is found to be running several times within a single

24-hour period due to the PDS becoming full, it is strongly recommended that the

PDS size should be increased until the job runs no more than once in any

24-hour period.

5.6.4 Tuning ITMS:Engine

The ITMS:Engine provides common functions such as communications,

diagnosis (dumps), and logging (RKLVLOG) for z/OS-based monitoring agents,

OMEGAMON II components of OMEGAMON XE products, plus z/OS-based

monitoring server. It has startup parameters defined with appropriate defaults for

most customer environments though for some customers with large amounts of

data to be transferred these defaults may be insufficient.

These parameters are defined in the data set pointed to by the RKLVIN DD

statement in the started task procedure for the monitoring agent or monitoring

server. Typically this would be as follows, where xx is replaced by the product

code for the monitoring agent or monitoring server:

&rhilev.&midlev.RKANPARU(KxxSYSIN)

If you find a message similar to Example 5-3 on page 180 in the RKLVLOG for an

OMEGAMON agent, it means an error has occurred when a monitoring agent

tried to return data for the table specified by the table variable and failed. The

most common cause of this error is a query that returns a large number of rows

of data, causing an out-of-memory condition.