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
