Use SMF to chase CPU spikes

[Abhilash Sharma]

I have been working on Which SMF types/fields do you inspect first when batch CPU jumps unexpectedly? Thanks in advance for sharing your thoughts.

[Anuj Dhawan]

I would start with SMF 30 subtype 4 at the job-step level - subtype 5 can hide which step caused the increase. Compare the affected run with a normal run using SMF30CPT and SMF30CPS, along with zIIP time, elapsed time, EXCP count and input volume.

If the step genuinely consumed more CPU, I would then correlate the same interval with SMF 70-1 for overall processor/LPAR utilisation and SMF 72-3 for WLM service-class activity. If increased I/O or a particular subsystem is suspected, I would continue with SMF 42-6 for dataset-level I/O or SMF 101 for Db2 accounting. The key is to compare the same job, step and similar workload volume - not just the job total.

[hollow_rowan69]

Anuj Dhawan's SMF 30 subtype 4 starting point is the right first cut, because subtype 5 totals can hide which step actually moved. Comparing SMF30CPT and SMF30CPS for the hot step against a normal run with similar input volume, then lining up SMF 70-1 and 72-3 for the same interval, separates a real CPU increase from LPAR or WLM delay. If EXCPs jump with CPU, SMF 42-6 or Db2 SMF 101 for that window usually shows whether I/O or SQL drove the spike. Keeping the comparison on the same job name, step and approximate record counts avoids false alarms from a heavier input file.