OMEGAMON XE for zOS 5.1.0 Problem Solving Scenario - USS Process gone WILD !
JoeWinterton 110000BXHR Visits (3386)
Here is an issue I ran into today. Lets look at the pdf file attached:
On Page 2 - I saw two alerts this AM - One for a possible CPU Looping address space on LPAR SYS and a second one for a USS Process using a large amount of CPU time. Lets look at these issues on LPAR SYS.
On Page 3 - We go to OMEGAMON XE for zOS and look at LPAR SYS and ask which Address Space maybe Looping? It is CTG90GP. Now I can cancel this right here but I really want to understand it better first. So lets look and see more about it before I do that.
On Page 4 - The USS Overview workspace on LPAR SYS shows the high using USS Process is ALSO Address Space CTG90GA and it is command JAVA. Now I joke about JAVA as it always seems to like to use the processor. It is burning a z114 CPU at 97% as we look at it. Let explore some more.
On Page 5 - We look the USS Details for the address space and see it has used 11 Hrs and 28 Minutes of a z114 CPU in the 15 hours it has been active. Now I think this is looping as this is extreme even for JAVA. Wow that is most likely looping as the second alert told us. We can explore it some more.
On Page 6 - If we look at Bottleneck Analysis for address space CTG90GP we see the cpu use too and then if we issue an INSPECT on the Using CPU line we see the Load Module as $OPENMVS and we can see the CSECT and offset to the code that looks to be looping. It is now time to CANCEL this address space and allow the LPAR SYS to process other work. I will give this information to the correct person running this address space so they can debug the looping code.
On Page 7 - We now see the Alerts have CLOSED for both the looping Address Space and the USS Process burning CPU alerts. The SYS LPAR has returned to other work.
Let OMEGAMON XE for zOS 5.1.0 keep a watchful eye out on your USS work to alert you of issues so you can handle them.