I appreciate the help and suggestions. And, if SAS was the only culprit, I'd work at isolating SAS. But, I can get a spike with just about any CPU biased work, I can come close with just a failing search in SDSF.
We can also live with the problem, if we have to. I was just exploring an idea, based on seeing the fields on the HMC panel. Still, tempted to try a value around 0.24 (36/151) > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of kekronbekron > Sent: Saturday, April 03, 2021 6:13 AM > To: [email protected] > Subject: Re: Low softcapping on high capacity CEC > > I know you said you were in wind-down mode; think you also mentioned > you're running in hosted infra? > You could consider > https://urldefense.com/v3/__https://luminex.com/products/mdi/slp/__;!!J > mPEgBY0HMszNaDT!84sfTqbyoeybG_E68pSIE2uvehESy- > lGH7cK5yNxYyW8tI1bOk1ch5-2ABBTEA$ > > In short, it's a VTL (could be tiny) that 'writes to tape' (via FICON) a copy > of > SMF, onto this box. > You can then get SAS/MXG license for this box and let it go wild. > Results can either be consumed by forwarding the reports from the box to > elsewhere or sending them back to mainframe. > Sending back to mainframe might not be desirable since it'll probably go > outside in the next step anyway. > > I don't know why more people consider Luminex or Optica zVT or other > 'smaller' VTL solutions, even when the products/solutions are better off for > some use cases. > > - KB > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, April 3, 2021 12:26 AM, Dave Barry <000000a5644c6d08-dmarc- > [email protected]> wrote: > > > We had the same issue with SAS driving up the R4HA. We put the work in a > service class with a resource group cap. The type 72 records gave us a > reasonable target service units/second for starters, and we reduced the cap > incrementally until we were satisfied. The jobs ran longer afterward, but all > finished before their deadline. > > > > Absolute capping sounds like an easy way out, but it wasn't designed with > your purpose in mind. It had to do with Linux partitions dynamically starting > and stopping occasionally as a means of responding to changes in resource > demand. You probably wouldn't do that with z/OS LPARs, which, once > activated, usually remain active for the long haul. > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM- > [email protected]] On Behalf Of Gibney, Dave > > Sent: Wednesday, March 31, 2021 12:01 PM > > To: [email protected] > > Subject: [EXTERNAL] Re: Low softcapping on high capacity CEC > > > > CAUTION! This email originated outside of the organization. Please do not > open attachments or click links from an unknown or suspicious origin. > > > > > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ========================================================== > ================================ > > > > My LPAR group, with my 4 LPARs is set with a cap of 12 MSU for z/OS > charging purposes. We pay for 12 MSU. ABSNSUCapping would, as I read it, > make permanent the condition I am trying to avoid, that is always being > capped at 12. > > Even if I could reliably identify the jobs, and online activity that are my > > high > CPU spikes, AFAIK, unless I am in a capped state, the CP resource, being > available, will be used. WLM doesn't care about anything when utilization is > less than capacity. > > > > The problem I'm addressing is to avoid becoming capped due to short > spikes up to the 151 capacity of the CPs. It doesn’t take very long for these > spikes to bring my 4/hr over 12. But, if I could have an limit on the size of > these spikes, say 24 MSU, I could still get the work done, and not spend long > periods actually capped at 12. > > > > What is the purpose of the HMC setting, Absolute Capping for CPs that first > gave me the idea that this was possible? What is the meaning of a setting > from 0.01 to 255.00 here? > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List [email protected] On > > > Behalf Of Scott Chapman > > > Sent: Wednesday, March 31, 2021 4:16 AM > > > To: [email protected] > > > Subject: Re: Low softcapping on high capacity CEC > > > As was mentioned, ABSMSUCapping may be useful in that you can limit > > > the entire group to a specific number of MSUs. I.E. if you defined the > > > group of 4 LPARs in a capacity group at 24 MSUs (or whatever) and > > > enabled ABSMSUCapping on all of them, all 4 LPARs would be capped (in > > > total) at that > > > 24 MSUs. > > > The Absolute CP Capping can work too, but you can't set the limit > > > across the 4 LPARs, so they can't borrow capacity from each other. > > > I.E. if you want the limit to be a combined 24 MSUs but you want each > > > to be able to consume up to 24 MSUs, then a group cap with Absolute > MSU Capping is the way to go. > > > If you want to limit individual workloads within the LPARs, then WLM > > > resource groups can do that for you. That's at a service class by > > > service class basis and most often are specified by SU/s (not the same > > > as MSUs). So assign the SAS work to a specific SC (BATHOGS?) and make > > > sure that SC has a resource group that limits how much CPU the work can > consume. > > > Scott Chapman > > > > > > 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
