Thanks Barton. ____________________ Jim Hughes Consulting Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-5586 Fax 603.271.1516
Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. -----Original Message----- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Barton Robinson Sent: Monday, February 07, 2011 4:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SET SHARE ABSOLUTE/RELATIVE Very few people understand the scheduler, and what it does - What it does, it does very well. You just have to understand the language. Rob did some recent experiments that validated how it works, and validated how little functions like VRM really help your workloads (except by accident). From the VelocitySoftware.com page, go to "Linux Hints and Tips". There is a new link there to Rob's recent research. I would recommend reading it and understanding it before setting shares (or using VRM). Hughes, Jim wrote: > Thanks for the reply Marty. Long time, no see. > > > > Our VSE systems are mainly interactive CICS or IDMS/DC systems during > the day. Night time they become batch machines. > > > > The CICS and IDMS/DC systems are mainly accessed via VTAM. > > > > Our three production systems are each set to ABSOLUTE 20% with no > defined target maximum. The sum of our ABSOLUTE SHARE users does total 100%. > > > > With that said, we've asked ourselves is ABSOLUTE 20% enough? > > > > The manual says once you have defined the minimum target ABSOLUTE SHARE > to total 100%, the scheduler reserves 1% for the RELATIVE SHARE users. > It goes on to say that once an ABSOLUTE SHARE user has reached its > minimum target share it only gets more if system resources are available. > > > > What I am looking for is a way to keep the production systems behaving > if a production vse system(absolute share), test vse system(relative > share) or a cms user(relative share) begins to loop. > > > > The more I read about CP SET SHARE the more I suspect it isn't designed > to be a panacea for smooth performance in time of trouble. > > > > Maybe I should be investigating the VM Performance Monitor to assist > with dynamic performance adjustment in a time of trouble. Comments? > > > > ____________________ > Jim Hughes > Consulting Systems Programmer > Mainframe Technical Support Group > Department of Information Technology > State of New Hampshire > 27 Hazen Drive > Concord, NH 03301 > 603-271-5586 Fax 603.271.1516 > > Statement of Confidentiality: The contents of this message are > confidential. Any unauthorized disclosure, reproduction, use or > dissemination (either whole or in part) is prohibited. If you are not > the intended recipient of this message, please notify the sender > immediately and delete the message from your system. > > ------------------------------------------------------------------------ > > *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] > *On Behalf Of *Martin Zimelis > *Sent:* Monday, February 07, 2011 3:01 PM > *To:* IBMVM@LISTSERV.UARK.EDU > *Subject:* Re: SET SHARE ABSOLUTE/RELATIVE > > > > Catherine, > I don't think your understanding of SHARE is backwards, but your > expectation of what the performance manager will do might be. I suspect > it's trying to keep heavy CPU users from hogging the processors. > > To get back to the original question, Jim, I think you need to > describe what the z/VSE guests are doing. If they're supporting > interactive users (e.g., CICS), you'd want one answer from the assembled > masses. If they're true batch workloads, the answer should be quite > different. Since your system's perceived responsiveness likely depends > on how quickly TCPIP (and VTAM) gets serviced, a high share is called > for. In your situation, is the same true for RSCS? Regardless, my > experience with the conventional wisdom of whether to use relative or > absolute shares is dated, so I'll leave detailed recommendations to > those with more recent experience. > > Marty Zimelis > > On Mon, Feb 7, 2011 at 2:13 PM, McBride, Catherine <cmcbr...@kable.com > <mailto:cmcbr...@kable.com>> wrote: > > A while ago a very experienced VM person from IBM suggested that we not > use ABSOLUTE unless you "absolutely" must cap off a guest to keep it > from running away with your real processors. We used that setting on > our test system only. > Our VSE TOR and VM guest TCPIP both had high relative shares (10000 > versus 3000 for regular production guests). > Then we started using a performance manager feature of VM Toolkit, it > managed share values for us. > It set everything the same after VM IPL, but by the end of a normal > production day our busiest guests had dropped to the lowest relative > share, the ones seldom used had the highest. Meaning my understanding > of how relative share worked was backwards or the gizmo in VM Toolkit > was. Hopefully Alan or Kris will expound. > > > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU > <mailto:IBMVM@LISTSERV.UARK.EDU>] On > Behalf Of Hughes, Jim > Sent: Monday, February 07, 2011 12:57 PM > To: IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU> > Subject: SET SHARE ABSOLUTE/RELATIVE > > I've read the CP COMMAND manual and the PERFORMANCE manual regarding the > SET SHARE command and how it works. > > Would someone care to comment on how you have used them for your z/VSE > production and guest machines? > > What would suggest for TCPIP/RSCS/VTAM SET SHARE values? > > Thanks in advance. > > > ____________________ > Jim Hughes > Consulting Systems Programmer > Mainframe Technical Support Group > Department of Information Technology > State of New Hampshire > 27 Hazen Drive > Concord, NH 03301 > 603-271-5586 Fax 603.271.1516 > > Statement of Confidentiality: The contents of this message are > confidential. Any unauthorized disclosure, reproduction, use or > dissemination (either whole or in part) is prohibited. If you are not > the intended recipient of this message, please notify the sender > immediately and delete the message from your system. > > >
