Thank you. Sent from my iPhone
On 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
