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
