zIIP engine hogged by one batch job

,
1

This has happened a few times, and I am wondering what can be done about it. We have 2 general processors and 1 zIIP engine, and both ADABAS and batch Natural are zIIP-enabled. We get super performance as a result of zIIP-enablement with well over 90% offloading rates - many times 95%+ and occasions of 99%+. The busier you make ADABAS be, the higher your zIIP offload rate is, and with batch Natural, key is to reduce the need to switch to TCB mode.

The thing that happens from time to time, though, is we’ll have a batch Natural job that is clearly on the zIIP processor and it seems to be hogging it. If it is a long runner, it slows down other jobs waiting for the zIIP to be free. In an example from this morning, this job ran about 3 hours and performed a TCB switch about once per minute on average, and ran up a 99.97% zIIP offloading stat on 6457516 ms worth of processing. Other jobs were started during this window that normally take less than 5 minutes and didn’t have an unusual or different amount of work to do that took 1 or 2 hours instead. SYSVIEW showed the GPs running at around 10-20% but the IIP was running pegged at 100% until this offending job ended and the system normalized.

Now - I thought - maybe erroneously - that if there was zIIP-eligible work but the zIIP wasn’t free that the work would be sent to the GPs in order to prevent this kind of backlog. From the stats it does this a little bit… but these jobs could benefit by doing it a bit more. Is there something I need to do to tell it to behave this way?

Stats from one of the impacted jobs that could have been relieved by a more liberal use of the GPs:

     - zIIP Processing Information -

Advanced zIIP Support Enabled
Number of GCPs 2
Number of zIIPs 1
zIIP normalization factor 2.80
Number of switches into TCB mode 64
Number of SRB starts 1
Total enclave CPU time 17223
Qualified zIIP CPU time 17140
Eligible zIIP CPU time on GCP 15
Total enclave zIIP CPU time 17125
Total enclave zIIP CPU time (%) 99.43

(All times in milliseconds; zIIP times normalized)

Thanks in advance!

2

Brian,

the first thing to check would be the IEAOPTxx setting of parameter IIPHONORPRIORITY.

If it is set to NO, then no fallback from zIIP to a CP will happen.

Cheers - Wolfgang

3

Hi Wolfgang,

Thanks for the response and suggestion. According to our platform team, the only parameters being set are:

ERV=500
PROJECTCPU=YES

I think that means the default of IIPHONORPRIORITY=YES must be in effect?

The PROJECTCPU parameter must be left over from our days before having zIIP but the IBM documentation doesn’t seem to convey if this has any effect on existing zIIP installations and I think has negligible impact.

-Brian

4

Hi Brian,

a couple of questions:

Is the problem always associated with one job?

If so, might the job have one of the following:

Extensive use of arrays with variables for subscripts (big cpu user)
cpu intensive adabas operations (e.g. use of SORTED BY in Natural)

steve