In this case the OP stated that they are PAYING for CPU cycles on a mostly idle machine, so to me the implication is that they wish to reduce their CPU cost by reducing idle CPU cycles.
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Allan Staller Sent: Tuesday, March 5, 2024 1:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to reduce the overhead of WLM? Classification: Confidential The most important resource in most shops is CPU and is usually the critical factor in WLM adjustments. Judicious user of SC period and IMPortance is far more effective in controlling the distribution of CPU. . I would not overload SYSSTC with work, this will prevent WLM from servicing really critical stuff (GRS, XCF, IRLM,..). However it’s not my dog. Another thought to the OP. Are you trying to reduce overhead because of a CPU shortage, or just curious? Think absolute value vs percentage. In Sandbox environments, very often something like WLM appears to be the largest consumer of CPU), but in absolute terms it is really minor. HTH, -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Tom Marchant Sent: Tuesday, March 5, 2024 7:59 AM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: How to reduce the overhead of WLM? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Would it help to have more of those address spaces in SYSSTC so that WLM doesn't try to manage them? -- Tom Marchant On Tue, 5 Mar 2024 01:03:27 +0000, Graham Harris <harris...@gmail.com<mailto:harris...@gmail.com>> wrote: >A few years back, I did a deep dive into tuning CPU usage across a >multitude of very small z/OS guests under z/VM, and WLM was certainly a >big hitter for many of them, but as there were so many instances, I was >able to see notable differences in WLM use between "LPARs", which was >obviously "of interest". >The upshot seemed to be that WLM costs had a fairly firm relationship >with the number of active address spaces on the "LPAR", presumably down >to the amount of sampling that WLM has to do against each address space >every 250ms (I think). I did enquire of IBM as to whether the sampling >rate could be "adjusted", and that came back with a negative response >(not really a surprise). >So the obvious answer may be to only have address spaces started, when >they are only really needed to be there. >Although you may need to assess the cost of stopping/starting those >address spaces, versus the background WLM cost. > > >On Mon, 4 Mar 2024 at 23:08, Wendell Lovewell < >000001e9c0ee0673-dmarc-requ...@listserv.ua.edu<mailto:000001e9c0ee0673-dmarc-requ...@listserv.ua.edu>> > wrote: > >> This is probably a strange question, but is there a way to reduce WLM cpu >> usage? Here's the situation: >> >> - The system is a lightly used development system. Unless something >> is in a loop (very rare), CPU % probably is usually less than 10%. >> And except for system regions & CICS, it's rare to have multiple jobs >> running concurrently. >> - Only one processor defined to the VM. No ZIIP either. >> - We are charged for CPU cycles. >> - WLM is the highest consumer of CPU. JES2, TCPIP, ZFS and SDSFAUX >> round out the top 5 consumers. >> >> There is a lot of information about WLM tuning, but as best I can >> tell almost none of it relates to reducing WLM usage. >> >> From reading the Init & Tuning manual, I'm trying these settings: >> AIMANAGEMENT=NO >> HIPERDISPATCH=NO >> CCCAWMT=450000 >> RMPTTOM=15000 >> >> I was thinking that perhaps reducing whatever processing intervals I >> could might help. But I can't tell these changes made a difference. >> (I don't have a tool to measure WLM usage.) >> >> Any suggestions would be appreciated. >> >> TIA, >> >> Wendell -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
