We are a minor customer in a Mainframe as Service environment. Changing LPAR weights takes a change order to the provider. I don't know anyway to limit low priority work, when the capacity is available. Having experienced the curve when fewr/faster processors reached one processor (z800-0A1), I will never again willingly go to a uniprocessor. And, it wouldn't take the CPU intensive task much longer to spin up past 12 MSU 4/hour average using only the 151 MSU available on one CP.
We pay for the MSUs based on a 12 MSU softcap setting. And, the pain isn't much when capped, I notice it in the sandbox before my users do. > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Attila Fogarasi > Sent: Tuesday, March 30, 2021 7:34 PM > To: [email protected] > Subject: Re: Low softcapping on high capacity CEC > > You can always vary CP offline to reduce the max capacity available to WLM, > or change the LPAR CP weights to reduce the max MSU for that lpar -- but > its tricky as both PR/SM and z/OS try to maximize usage of available > capacity, including donating unused MSU from other lpars. You should be > able to work out a weight formula for your 4 lpars that gives max of 2x > your softcap, however that means you also can never use more even in short > bursts. That sounds like frying pan to fire to me. Probably more > productive to isolate and classify your lower priority work and limit the > throughput for that. z/OS works hard to use every evailable mip, and you > want to prevent that without any parm to do so directly. I've seen a lot > of systems, and never came across your request before :) Normally its the > other way (how to get more). > > On Wed, Mar 31, 2021 at 1:04 PM Gibney, Dave <[email protected]> wrote: > > > 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 <[email protected]> > On > > > Behalf Of Attila Fogarasi > > > Sent: Tuesday, March 30, 2021 5:31 PM > > > To: [email protected] > > > 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 <[email protected]> > 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 [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 > > > > ---------------------------------------------------------------------- > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
