You got zOS LPAR MQ delay questions? -- well we got answers !
JoeWinterton 110000BXHR Visits (3321)
Problem solving example with OMEGAMON XE on zOS V5.3 using RMF Monitor III DDS in the Enhanced 3270UI is pretty slick.
So we ask now with the "X" at 8 AM -what the work delays look like on SYSPLEX ZPETPLX2 for CPC 094E15 and the RMF MII data shows us, We click to sort it by CPU Wait percentage and look at what a great job WLM is doing as the Service Classes that are delayed are our discretionary Service Classes so WLM delayed the correct work until we get down to the CSQ1MSTR - MQ address space running on Z1. Lets explore that LPAR and address space at 8AM time frame.
Who and what are impacting CSQ1MSTR at 8AM? We see the biggest impactor for general purpose processors as CICS3A1A and it impacts CSQ1MSTR 19% of the time(cut off but trust me on these). We also see device P2PP34 and it is a minor 3% impactor.
Lets also look at 8AM for the whole Service Class STCI2V40 and we see many MQ address spaces delayed too across all the SYSPLEX LPARs.
Looking back at our CSQ1MSTR for details of the address space at 8AM we can see a complete picture of its use of CPU, Real Storage, Common Storage and Memory objects(some values cut off here) at that time.
This all takes me back to maybe where I should of started in the first place, looking at the CPC itself and how our SYSPLEX LPAR Z1 is setup to get a share the machine. CPC 094E15 is very stressed at 97.3% busy at this time. When I look at Logical CP percent vs Physical CP percent Effective and Total, the share Z1 is just not getting enough processor power to allow it to service our Service Class STCI2V40 Z1 work any better.
Looking at LPAR Z1 share of the CPC 094E15 we get more details and it shows it does not have capping on.
Now we could also quickly go over to the OMEGAMON XE for Messaging workspaces and see how the queue manager was handling the work during this timeframe where the LPAR was not getting enough CPU. It is a sea of RED here so we are having impacts in the timeframe.
We can continue to explore MQ CSQ1 queue delays and issues from here too.
This scenario shows from the OMEGAMON XE on zOS v 5.3 with the Enhanced 3270UI now using the RMF Monitor III DDS history information to follow a question of why my MQ work was not performing at its best at 8AM. We looked back and were quickly able to see the CPC was not giving enough CPU to this workload to have it perform better. Very powerful and it answers my question quickly.