To facilitate understanding of the factors affecting CPU utilization, readers should be familiar with the monitoring methods (see section “Acquisition of monitored data”).
Method based on monitoring cycle
At the end of the monitoring cycle, the measured values of the previous monitoring cycle are calculated for all monitoring programs (with the exception of TASK). In contrast to the sample cycle, the monitoring cycle is so much longer that system utilization by this method based can be disregarded.
Method based on samples
A monitoring task routine is activated at specific intervals (see the SAMPLING-PERIOD operand of the MODIFY-MEASUREMENT-PERIODS statement on "MODIFY-MEASUREMENT-PERIODS Modify SM2 monitoring cycle") to take samples.
For each activation of the sampling routine, a basic load has to be processed, regardless of the variables (devices and tasks) to be monitored.
In addition to this basic load, further instructions are processed which depend on the number of objects to be monitored (devices, channels, tasks).
If this number remains constant in the monitoring cycle, CPU utilization is almost directly proportional to the sampling rate (i.e. halving the sampling cycle, for example, causes the induced system load to be doubled).
Lengthening the sampling cycle should be balanced by lengthening the monitoring cycle to prevent a deterioration in sampling precision.
The sample-driven method is used for device and channel utilization, the length of queues, and the monitoring programs CMS and TLM.
Method based on events
When this method is used, the monitor is the “passive” component in contrast to the other system components, which are “active”. When specific events occur in the system (e.g. starting of an I/O operation), specific monitoring programs are activated which collect the relevant data (e.g. which device, which task, etc.).
While the monitor is inactive, no system utilization is induced.
If, however, events occur which are to be monitored, utilization increases in proportion to the load (i.e. to the number of calls).
When this monitoring method is used, the system load can be reduced only by reducing the number of objects to be monitored.
The event-driven method is used by the monitoring programs CHANNEL-IO, DISK-FILE, FILE, ISAM, PERIODIC-TASK, RESPONSETIME, SAMPLING-DEVICE, SERVICETIME, SYSTEM and TASK and by all user-specific monitoring programs.
UTM monitoring program
If UTM applications are running on the system and these applications provide data for SM2, the following additional load occurs in each UTM task: an additional 500 instructions (approx.) are required at the end of each dialog step and each asynchronous conversation in order to provide this data. For a typical application, this amounts to considerably less than 1% of the entire processing volume.
The resulting additional load on the system thus depends on the throughput in the applications, but can generally be ignored.
If values are also provided from the database systems, an additional load arises in these database systems in order to capture the monitored data. This load depends on the database system itself and the version used. For this reason, no general rule can be given.
Write task and I/O buffer
SM2 creates a write task (system task with TSN=SM2W) for writing to the SM2 output file. This task exists only from OPEN to CLOSE and is activated only when an I/O buffer is full. The input/output operation is controlled by the write task, and the CPU is required for task execution (CPU time for TPR and SIH states). The CPU time required for writing to the I/O buffer is assigned not to the write task but to the initiating task (system task or SIH processor state).
The data rate for writing to the I/O buffer depends on whether the record is written
by the monitoring task at the end of a monitoring cycle,
by another task, or
in the SIH processor state
In the first case, the data rate depends on the number of active monitoring programs (data records) and monitored objects, as well as the duration of the monitoring cycle (OFFLINE-PERIOD operand in the MODIFY-MEASUREMENT-PERIODS statement). If the same data records remain active during monitoring, the workload is inversely proportional to the duration of the monitoring cycle. The second and third cases only apply to the monitoring program TASK.
TASK user-specific monitoring program
The system load caused by the TASK user-specific monitoring program activated by means of the /START-TASK-MEASUREMENT command is primarily due to the PCounter statistics and the SVC statistics.
Program counter statistics
The system load caused by program counter statistics depends on the following factors:
the sampling cycle selected
the number of tasks monitored