All, Maybe a really dumb answer so please do help me shape my understanding.
If it's known jobs/user programs that cause the spike, a) Would it help if they were put on discretionary service class? b) How about using automation to RESET xxxx,QUIESCE and RESET xxxx,RESUME to freeze the CPU-hungry address space, to keep the growth of 4hra controlled? Alternatively, with one of the RMF address spaces (RMFGAT or RMFM3B), you can use one of the relevant CLIST/REXXs in SYS1.SERBCLS to print out 4hra and MSU Actual every 2 mins or so. Then, when it goes past a threshold, you can use automation to RESET QUIESCE/RESUME to throttle that particular task. This should give you room to work in before 4hra hits the DefCap. The business-y answer is to get a product to manage this for you. But yeah, the above RMF WTO-based feedback loop is what I would go for, considering that your shop is winding down anyway. Also if possible, I'd look at what's causing those CPU spikes and consider moving it around to 4hra quieter times. A game of whack-a-mole... - KB ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, March 31, 2021 8:24 AM, Gibney, Dave <gib...@wsu.edu> wrote: > 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 IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of Attila Fogarasi > > Sent: Tuesday, March 30, 2021 7:34 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 gib...@wsu.edu 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 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 IEAOPTxx > > > > 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 > > > > 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
