Analysis of CPU By Plan: CICS Transaction (110.1) and Db2 Accounting (101) Part 2

This video shows an example of how integrated visibility between Db2 Accounting and CICS Transaction data can correlate CICS transaction IDs driving high CPU in Db2 with the CICS profile of the transaction including transaction rate, CPU per transaction, and SQL calls per transaction.

More Integrated Visibility Resources

1. Leveraging XCF Message Activity for CPU Efficiency
2. Troubleshooting WLM Missed Goals with CICS Transaction Data
3. Address Space and Db2 Accounting Data
4. Dataset Performance (42.6) and Db2 Buffer Pools & Databases (SMF 102/IFCID 199)
5. Db2 GETPAGE Efficiency – Dataset Performance (42.6) and Db2 IFCID 199
6. Elapsed Time Profiles by Correlation ID: CICS Transaction (110.1) and Db2 Accounting (101) Part 1
7. Analysis of CPU By Plan: CICS Transaction (110.1) and Db2 Accounting (101) Part 2
8. Insights You Can Gain from Integrated Visibility Across Types of SMF Data

Video Transcript

Alright, I want to now talk a little bit more about kind of CPU use that’s going on within Db2. So let’s go over here to this view of class 2 CPU, which is Db2 time within Db2. Again, we’re having a discussion here about CICS in Db2 visibility. So I want to just look at Db2 work that’s coming in through CICS Call Attach, and not any of the other Connection types. So I’m gonna go ahead and set that global filter. Okay, so now here are the Plans that are consuming the most Class 2 CPU time, those CPU time within Db2. And let’s go ahead and look at this as a line chart. And again, I’m gonna zero in, maybe on the top five. Okay. Let’s go ahead and add that to our dashboard.

Okay, see for this this Plan that’s consuming the most CPU, you know, kind of the common day profile, and then a bit of a jump up in the evening. So I’m interested kind of in the day-by-day profile of this Plan across the week. So let me broaden it out. And when I do that, I see that almost every day I’ve got a jump up in CPU right around the eight o’clock timeframe. I’ll go ahead and capture that.

Okay and then we said within the Db2 Accounting data captures the CICS Transaction ID. Now, again, if I look at this by Correlation ID, now I can get a view of it by the tran codes. And again, I wanna look at this over time. So here’s a transaction that’s kind of jumping up there. Again, let me look at this over the week. So I can see here now that this particular transaction is responsible for driving those evening CPU jumps, right? I got the normal daytime profile, and then I’ve got these jumps in the evening that are being driven by that GYEV transaction.

So, now that I’ve identified that going on on the Db2 side, let’s go over to the CICS side and look a little bit more at that transaction – see what we can learn about it. So I’m gonna go over here now to CICS, and we’re gonna look at CPU. We’re gonna look at CPU and then I’m gonna set a filter, cuz right now I’m wanting to focus specifically on that transaction.

Okay, so let me look at that now over time, and this is total CPU consumption by zIIP and GCP, of course, it’s almost all GCP. So I’m gonna shift here and instead I wanna look at this as CPU per tran and look at that profile.

Now then the other thing I’m interested in here is now that I’ve got CPU per tran, I’m also interested in the transaction rate because we’re trying to understand why we have those jumps in CPU in the evening. And I see now that, you know, the tran rate is up a little bit, but not nearly as high during the day, but the CPU per tran is what has jumped dramatically, right? So that’s what’s driving the fact that that transaction is a big CPU consumer in the evenings.

So, now again, I’m in the CICS transaction data and I’m seeing this jump in CPU per tran, and I saw it over on the Db2 side. So, you know, my next working theory is that I’m making a bunch of SQL calls here, right? So let’s go ahead and look at the rate of SQL requests from this transaction. And sure enough, we do have a huge jump, right? I think it’s more than 10 or 20 fold jump in the number of SQL calls that are happening here, which certainly fits with what we saw in the CPU within Db2.

So let, let’s go ahead and also put that CPU per tran back in this view as well. And we can see that they correlate so well that at times you can’t even see the one line versus the other one, right? So again, we’ve got on the Db2 side, we saw that the Plan CPU was up in the evening hours because of that transaction. We go over to that transaction, it’s not because the tran rate is particularly high, but the CPU per tran is off the charts and it correlates to a high volume of SQL calls. So again, as both teams have visibility into the data on both sides, then you’ve got collaboration and you’ve got clear visibility into what’s driving the observed behavior that’s being seen.