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

Reply via email to