Since you mentioned Adabas, I believe throwing some zIIP at it (& licensing this feature from Adabas's vendor) will help reduce CP usage. In addition to WLM, I would also look at LPAR Design Tool to check out VH/M/L spread (tuning the weights and engines per LPAR). Could be wrong... but I think WLM really matters only when things are getting tight on the LPAR/machine.
It's surprising to me that BC machines are being used for tiny capacities (15 MSUs?). Just curious... is it cost effective keeping this going? Maybe it's not an option to migrate 'cause there's old code? - KB ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, October 14, 2020 1:25 PM, Martin Packer <[email protected]> wrote: > Hello Shivang! > > Either LPAR busy or - my preferred metric and embedded in my regular > graphing - how much CPU the service class is taking. > > Certainly the general point of considering what you’re achieving in > velocity terms, why, and how it varies under increasing load is a good one. > > I would also plot each day a different marker / colour - as that technique > has helped me trouble shoot. The famous case is one where a customer’s > “outage” - on a bad day - was just data points continuing the normal line > towards doom. :-) Plotting those “outage” points in a different colour > helped make the point. > > But most of the time a bad day is a set of points that are well below the > usual curve - and then you go to a companion graph that shows the > components of the velocity calculation stacked up. So you get to “today our > Db2 Engine Service Class velocity tanked due to Delay For zIIP”, for > example. > > Somewhere I blogged/podcasted/screencasted/presented or something :-) about > all this. > > Cheers, Martin > > Sent from my iPad > > > On 13 Oct 2020, at 23:43, shivang sharma [email protected] wrote: > > You can draw lpar busy vs velocity of the service class to see what it > > achieves when the lpar gets busy and get the number. > > > > > On Wed, 14 Oct 2020, 3:06 am Jerry Whitteridge, < > > > [email protected]> wrote: > > > Dave - I'm by no means a Capacity Planning guru but here's my 2 cents. > > > Velocity is defined as a measure of protection against delay - it's not > > a > > > > hard and fast number. I'd first look at your service classes and find if > > > any of them have a PI of less than 1. If they do they are over achieving > > > their goals and you could drop the velocity on them to provide resources > > to > > > > the service classes who are struggling. Adjust the Velocities by 10 > > rather > > > > than single digits. All the tuning of the high achieving (not High > > > Importance or velocity) Classes will provide help to the under > > achievers. > > > > Jerry Whitteridge > > > [email protected] > > > Manager Mainframe Systems & HP Non-Stop > > > Albertsons Companies > > > -----Original Message----- > > > From: IBM Mainframe Discussion List [email protected] On Behalf > > > Of Gibney, Dave > > > Sent: Tuesday, October 13, 2020 2:28 PM > > > To: [email protected] > > > Subject: EXTERNAL EMAIL: Max possible velocity? > > > It has been quite some time since I had to worry about my WLM policy. > > > We've had ample capacity since 2007. Now, as We begin to wind down, we > > have > > > > reduced our contracted MSU capacity. > > > We dropped from 15 to 12 on an 5 way z13S-N05. My WLM policy, last > > > seriously adjusted in 2007 when we moved to a z9-L03 has velocities > > ranging > > > > from a high of 90 (Adabas, Imp 1) down to 5 (BATCH Imp 5) > > > We are experiencing just a minor amount of performance pain. It strikes > > me > > > > that perhaps some of my higher velocity goals (90, 70, 60, 50) may be > > > unattainable under the now reduced capacity. > > > What is the high end for possible, single threaded (Adabas) velocity > > here? > > > > Or, where should I be reading in current manuals. I was better at this > > 15 > > > > years ago. > > > 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 > > > > > > Warning: All e-mail sent to this address will be received by the > > > corporate e-mail system, and is subject to archival and review by > > someone > > > > other than the recipient. This e-mail may contain proprietary > > information > > > > and is intended only for the use of the intended recipient(s). If the > > > reader of this message is not the intended recipient(s), you are > > notified > > > > that you have received this message in error and that any review, > > > dissemination, distribution or copying of this message is strictly > > > prohibited. If you have received this message in error, please notify > > the > > > > sender immediately. > > > > > > 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 > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > 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
