1) zAAPs were only doing Java work. The z10 machines at the time had no option for zAAP on zIIP, so we're talking about real zAAPs here, which only are eligible for Java work.
2) Yes, when I said "zAAP-eligible" I meant just JVM work, not including stuff that isn't eligible. For example, if you look at the Websphere address spaces, the servants running the application Java code are almost all eligible. But the daemon, node agent and server all do more work that's not eligible. If you look in SDSF, there are a few data columns of interest: JOBNAME CPU-Time GCP-Time zAAP-NTime zACP-Time zAAP-Time ECPU-Time P3SR01AS 2189.20 22.08 2039.81 6.72 328.21 3225.14 P3SR02AS 7197.24 65.00 6995.91 13.61 1125.67 9299.76 P3SR02A 1303.91 663.30 582.25 0.78 93.68 1303.91 P3SR02BS 7536.53 65.27 7314.36 12.95 1176.91 9854.92 P3SR01A 516.91 106.61 381.86 1.47 61.44 516.91 P3SR01BS 1997.09 14.32 1849.42 5.75 297.58 2086.93 P3DMGR 5358.58 656.19 4511.57 30.37 725.93 5358.58 P3SR02B 1314.07 649.79 603.67 0.92 97.13 1314.07 P3AGNTA 3111.00 418.39 2495.72 8.96 401.57 3111.00 CPU-Time is the total normalized time across all the processor types. IIRC, ECPU-Time includes some enclave time that CPU-Time does not. GCP-Time shows the time on the GCPs. zAAP-NTime, is the zAAP time, normalized to the GCP speed, whereas the zAAP-Time column shows the non-normalized values. (Since those are different above, you can see I'm running on sub-capacity GCPs and the normalization factor is about 6.2x.) zACP-Time is the time on the GCP that was zAAP-eligible but for some reason ran on the GCP. You can see that 's very tiny. It will never be zero because of the way some interrupts are handled, but with IFAHONORPRIORITY=NO it can be very small. Note that "NO" is not appropriate in all situations. So when I said ">95% of their zAAP-eligible time is on the zAAPs," I meant zACP / (zACP+zAAP-N). Here's an example though where it works out to 94% though: JOBNAME CPU-Time GCP-Time zAAP-NTime zACP-Time zAAP-Time ECPU-Time RTMSERVE 14639.67 7958.27 6564.75 421.45 1056.30 14639.67 RTMSERVE 3708.42 275.12 3392.55 8.20 545.88 3708.42 That first address space spends a fair amount of time calling REXX scripts from the JVM, so there's more swapping backs and forth between the GCP and zAAP, and that's probably got something to do with why it has more zACP time. You'll also notice that ECPU-time = CPU-Time in this example, supporting my recollection that ECPU-time has something to do with the enclave time as there's no enclaves involved here. All this data is also in the type 30 SMF records. I'm glad you found the post interesting. Scott On Thu, 28 Aug 2014 08:24:59 -0500, Elardus Engelbrecht <elardus.engelbre...@sita.co.za> wrote: >>the z10 zAAPs stayed at right around 15-20% busy or so. > >With or without, for example, DB2 work offloaded to zAAP? > >>With that set to "no" I think all of my JVMs show >95% of their zAAP-eligible >>time is on the zAAPs, and >98% is not uncommon. > >Just curious and if you don't mind please, what did you used to measure those >usage percentage? Are only the JVM work measured or not? > >>I don't think I answered your question, but hopefully I've given you some >>things to think about. > >But you gave a good general answer. I believe many on IBM-MAIN can learn from >it. > >Many thanks! > >Groete / Greetings >Elardus Engelbrecht > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
