You may ask IBM or your Business Partner to do a CP3000 study. This can uncover issues with WLM.
On Wed, Dec 17, 2014 at 11:36 AM, Ted MacNEIL <[email protected]> wrote: > > PR/SM (LPAR) doesn't know PROD from TEST. > It only knows weight. > If you have set it up for LPAR to have 80% and LPARB to have 20%, that's > what they get in times of contention. No more, no less. > 20% is one's allotment so it's okay. 85% is above the allotment so it's > scaled back to 80%. > This is how it's always worked. > > > - > -teD > - > Original Message > From: L Hagedorn > Sent: Wednesday, December 17, 2014 11:15 > To: [email protected] > Reply To: IBM Mainframe Discussion List > Subject: Re: MIPS, CEC, LPARs, PRISM, WLM > > Thank you for the extensive information and examples. > > I will be hitting the books. > > Can you expand on this example: > > If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and > LPARA will be squeezed to 80%. > > It seems counter intuitive to me and I'd like to understand. Lets say > LPARA is prod - they should get most of the resources. Why would LPARA be > squeezed instead of LPARB? > > Sent from my iPhone > > On Dec 17, 2014, at 9:07 AM, "Staller, Allan" <[email protected]> > wrote: > > > The answer is, "it depends". > > > > First, there is no "priority" across LPARS. All LPARS are dispatched > "equally" according to the LPAR weights. > > > > For example, if LPARA is weighted are 80 and LPARB is weighted at 20, > the following occurs: > > > > If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy > and goes on their merry way. > > > > If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% > and LPARA will be squeezed to 80%. > > > > If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy > and goes on their merry way. > > > > The LPARA weight represents a "guaranteed minimum" proportion (note: > LPAR weights need not total to 100. The proportion is relative.) > > > > All of the above occurs when capping (either hard or soft) is not > present. > > > > Software capping can occur with resource groups. > > Hardware capping can occur with group capacity limits. > > > > This is a complex subject and much more than can be covered in a short > e-mail. > > > > If you have not already done so, I suggest you obtain a copy of and read > the PR/SM Planning Guide. The most recent version I can find is > SB10-7155-01 and is located here: > > > https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570&aid=1 > (watch the wrap). > > > > RMF Monitor I (batch) has an excellent CPU report. This will also > include the "PARTITION DATA REPORT". I will refer you to the fine manuals > for details/ > > > > WLM *may* reach across LPAR Boundaries. If fact, it is designed to do > this. However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a > factor. > > > > As others have pointed out, what evidence is there that the "runaway" > task is affecting "production" (factual, not conjecture!)? > > > > HTH, > > > > <snip> > > We have a situation with multiple LPARS on a CEC, running DB2 asids > prod, test, dev. > > > > It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU > and stealing MIPS from the PROD LPAR and affecting production. > > > > Others claim this is not possible due to Prism. > > > > Will someone provide an overview of how Prism influences or controls > MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting > or controlling factors (if any), and how can the behavior be measured or > reported upon so I can explain this with supporting doc? Does WLM play a > part in sharing CPU across LPARs? > > </snip> > > > > ---------------------------------------------------------------------- > > 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 > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
