Additional update on our configuration. We have a z15-T02, with two physical engines. Our production LPAR has one dedicated GCP and shares the second GCP with the Development LPAR. Since Development only has access to only one physical processor, our performance and tuning company feels that adding another logical GCP would not help. They have pointed out that the DB2 work coming from the DB2 batch jobs, may be generating SRBs, which are always dispatched before TCBs and due to the capping, TSO and other work gets delayed.
Sent with Proton Mail secure email. ------- Original Message ------- On Wednesday, August 9th, 2023 at 11:02 PM, Graham Harris <harris...@gmail.com> wrote: > I have seen Db2 unloads use vastly more (overall total) CPU when doing > parallelised processing, compared to non-parallelised. > Obviously you are doing reload (I presume) rather than unload, but the same > thing may apply. > So might be something worth checking/testing, if parallelism is relevant to > your situation. Not just for the overall CPU aspect (which was never > determined as to whether it was an actual bug or not, as far as I > remember), but also with regard to the numerous threads that would be > trying to dispatch simultaneously, and the contention that would generate > on a single CP LPAR. > > On Wed, 9 Aug 2023 at 17:06, rpinion865 < > 0000042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > > > Well, for starters the DB2 address spaces are in a service class named > > STCHI, which has the following WLM definitions. > > Importance Level 1 with an execution velocity of 55. Regarding the > > situation when "DB2" uses most of the CPU. It is > > not the DB2 address spaces that max out the CPU, rather the batch jobs > > using DB2, in this case a batch job to restore > > a database. We have a third party who does our performance management and > > makes recommendations. We have asked them > > to look at the DB2 batch jobs. One comment they made was that the > > database restore may be invoking internal sorts, > > with little I/O interrupts. Therefore allowing this batch job, with the > > related WLM controls, to dominate the CPU. > > > > Which is why I think adding another logical CP to the LPAR would help > > other work. What we have to be very careful > > about is not to increase the MSU usage of this LPAR. We run several IBM > > and non-IBM products on this LPAR that have > > their pricing based on the capped MSU usage for this LPAR. > > > > Sent with Proton Mail secure email. > > > > ------- Original Message ------- > > On Wednesday, August 9th, 2023 at 11:24 AM, Rebecca Martin < > > 0000050348c1817e-dmarc-requ...@listserv.ua.edu> wrote: > > > > > By any chance do you have your Db2 address spaces in SYSSTC? If yes, get > > > them moved out AND share give development uses of both logical CPs. > > > IRLM should be there but the others should. On a 1 CP system, all > > > regular work stops while a task in SYSSTC is using the CPU. High CPU users > > > like Db2 should not be in SYSSTC; especially on a system with only 1 > > > logical CP. > > > > > > ---------------------------------------------------------------------- > > > 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 > > > ---------------------------------------------------------------------- > 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
