Something to be aware of when looking at CPU delays being reported by RMFIII, is that in multi-tasked asids, if ANY of the subtasks is found to be in CPU wait when RMFII does it sampling sweep (once per second), then that sampled second will have a 'CPU wait' associated with it, applying to that asid. Even if it is one task out of 30 experiencing a delay, that whole second sample will be attributed as CPU wait. Thus it can produce highly misleading numbers. Dont know if this is documented somewhere, but I had this behaviour confirmed via PMR several years ago.
Have you compared with RMF1 data? Also, if you have 30 subtasks running on a 12-way (or 5-way?) LPAR, then I would have thought you are pretty likely to have at least one subtask waiting for access to a CPU now & then. And I imagine that being a DB2 reorg, it is presumably driving a reasonable amount of I/O, and is not necessarily specifically CPU bound. On 29 September 2016 at 18:06, Peter Hunkeler <[email protected]> wrote: > >You have to dig into queuing theory, arrival rate, arrival pattern, and > service duration of the work to understand why RMF is reporting CPU > delay samples yet WLM does not unpark processors to run it. > > > I think I have an idea of this even without knowing the theories. > > > >HiperDispatch is a balancing act between providing the best processor > efficiency vs dispatch responsiveness. If the average CPU utilization > of the 3 CPUs is not relatively high *and* the delay for work to get > dispatched is small, such that the cost/delay of using the vertical low > CPUs is believed to not be worth it, then the vertical low CPUs will not > be unparked. > > > After reading and thinking about HiperDispatch in depth, this was kind of > my conclusion and the reason I started this thread. I still have the pre > HiperDipatch way of how dispatching worked in mind and had to lear it is > all completely different now. That is why I started to doubt higher > priority would help. I think now it would not or not much. > > > As always with questions about complex things where the questioner has > limited knowledge, it is difficult to find out what exactly to ask. > > > > >You can always try turning HiperDispatch off and see what happens. > > > Not really. This is a rather large environment and it is only very few > jobs that show this symptom. I doubt I will be allowd to switch it off, and > more yet, I trust, overall, it would hurt than not. > > > -- > Peter Hunkeler > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
