Last I looked, WLM didn't take action at less than full CPU utilization. Even discretionary work can push a CP to capacity for brief periods if there isn't anything more important ready to run. We rarely really reach CPU constrained processing, and never for long periods, unless we are actually capped.
This new parm would keep us to low, all the time. I'd like a steady limit at about twice my softcap for z/OS cost (4/hour)purposes. ABSMSUCAPPING=option Specifies whether a defined capacity limit or group capacity limit is to be enforced only while the long term four-hour rolling average consumption is greater than or equal to the defined limit, or if it should always be enforced. In the syntax, option is either YES or NO. NO The defined capacity limit or group capacity limit is enforced only while the long term four-hour rolling average consumption is greater than or equal to the respective limit. IEAOPTxx 388 z/OS: MVS Initialization and Tuning Reference YES The defined capacity limit or group capacity limit is enforced permanently, independently of the long term four-hour rolling average consumption. Default: NO Absolute MSU capping requires an IBM zEC12 (GA2), or later, server to become effective. > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Attila Fogarasi > Sent: Tuesday, March 30, 2021 5:31 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Low softcapping on high capacity CEC > > You might want to check out AbsMSUcapping=YES in the IEAOPT*xx* > member of > parmlib. Probably the closest you can get to what you want at the system > level -- from your description it sounds like your problem is workload > priority and definition not being correct, WLM has controls like velocity > precisely for your SAS example but in modern era velocity throttling is not > often used as it is painful to categorize the large workload volume and > diversity on modern systems (also not generally useful or needed). WLM > allows 100 service classes to be defined, each with different velocity goal > if that is what you need. > > On Wed, Mar 31, 2021 at 8:56 AM Gibney, Dave <gib...@wsu.edu> wrote: > > > I am running 4 lpars in a LPAR group with group capacity set to 12 MSU. > > This is on a 5-way, z14 with a total of 756 MSU. Which is, give or take, > > 151 MSU/CP. We are on path toward decommissioning after we finish > > archiving the historical data. All production applications have shifted to > > cloud base services. ☹ We intend/hope to go to lower soft caps to save > z/OS > > licensing costs. > > > > With just the softcap in place, it doesn’t take very long for a CPU > > intensive task to raise us above 12 MSU 4-hour moving average, kicking in > > the cap for extended times. Just a short burst of SAS can do it. > > > > Recently, while looking the HMC screens , I noticed “Absolute Capping > > from Cps” on the HMC LPAR Group screen. I had hoped that I could define > a > > MAX MSU control here, probably about 24. (we lived on a z9 with about > that > > per CP for a decade) But, this setting is “Number of processors (0.01 to > > 255.00)”. Which doesn’t appear to be what I hoped, or need. > > > > > > Is there a way to accomplish my need (limit the height of CPU peaks)? > > > > Dave Gibney > > Information Technology Services > > Washington State University > > > > > > ---------------------------------------------------------------------- > > 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
