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 <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
