CPU workloads are considered heavy when they exceed 90%.
A heavy CPU workload does not necessarily mean that the resource CPU is the source of the bottleneck.
If you have determined that the rate of CPU utilization is high (the number of CPUs used by BS2000 must match the number of actually available CPUs), you must first check whether the CPU resources are being used efficiently. You can do this by studying the relationship between the workload in processor states TU and TPR and the workload in processor state SIH (see the notes on "Report group CHANNEL").
Try to achieve the following ratio:
TU + TPR > 3 * SIH (/390 server) or TU + TPR > 7 * SIH (x86 server)
If the ratio is poor, the investigation should be conducted with the objective of reducing the SIH time, which is essentially nonproductive for users:
Checking the level of the DMS I/O rate (see section "I/O load").
Checking the level of the paging rate (see section "Paging").
All calls to BS2000 are handled via SVCs. The processing of SVC interrupts involves corresponding overhead in the system, which is charged to the account of the calling task.
The total number of SVCs can be determined via report “Sum SVC calls”. The TASK monitoring program of SM2 can be used to count the number of SVCs for each task. Further classification in the form of SVC statistics is possible by means of user task measurement for selected tasks followed by SM2-PA analysis.
The following relationship helps to assess whether the resource CPU is forming a bottleneck in conjunction with heavy CPU workload and efficient utilization:
Wait time for using the CPU / hardware service time of the CPU
Standard value
The resource CPU can be regarded as overloaded when the main application yields the following ratio or the background application yields a correspondingly higher ratio.
Wait time for using the CPU / hardware service time of the CPU > 3
If long wait times for use of the CPU occur for the main application, there could be one of two reasons:
the system control parameters (in particular the priority assignment) were not set in accordance with the actual requirements;
the total CPU time requirement of all tasks is too high (critical case).
Further information is provided by the dwell time percentages in the system queues of the SM2 monitoring program SYSTEM (evaluation with the SM2R1 statement //PRINT-QUEUE-TRANSITION).
Example 1
CPU utilization | 96 % |
TU portion: | 36 % |
TPR portion: | 45 % |
SIH portion: | 15 % |
Main application: TP task category
Dwell time in 01 (%) / Dwell time CPU (%) = 5.4% / 1.2% = 4.5
background application: Batch task category
Dwell time in 01 (%) / Dwell time CPU (%) = 2.1% / 1.4% = 1.5
By choosing a poor setting for the system control parameters, the background application BATCH does not run in the background as intended. This forces the tasks in the main application TP to wait too long for use of the CPU.
Remedy: Assign a higher priority to main application TP or use PCS (see section "PCS concept").
Example 2 CPU utilization | 96 % |
TU portion: | 36 % |
TPR portion: | 45 % |
SIH portion: | 15 % |
Main application: TP task category
Dwell time in 01 (%) / Dwell time CPU (%) = 5.4% / 1.2% = 4.5
background application: Batch task category
Dwell time in 01 (%) / Dwell time CPU (%) = 16.8% / 1.4% = 12
The total CPU time required by all tasks is too high. The CPU resource is overloaded.
If the CPU workload is heavy and the performance demands of the individual users are not being met despite efficient utilization and short wait times, the resource requirements per user request (e.g. CPU time required per transaction) are too high (see section "Examining application performance with openSM2").
Figure 17: Tuning approaches in the case of high CPU utilization