Re: CPU capping is not working for one Lpar only on CEC?
>Besides, the software MSU figure is not the best thing to use for performance >and capacity planning studies. >It was designed by IBM solely as a way to keep software costs down. You still have to take MSU's into account. Especially, in Capacity Planning. It does no good to come up with a configuration solution that is financially infeasible. >The software MSU to machine power ratio has been changing to the customers >favor with each new hardware release. That's true, but it's just a constant. But, unfortunately, you have to take the software constant into account. I've been arguing with IBM, since 1984, when they introduced capacity-based pricing, in the form of model groups. Everything since then has been half-*ssed solutions to address the problem they introduced. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping is not working for one Lpar only on CEC?
Cobe, Another thing is that as someone posted it looks like your trying to use the hard cap by setting a weight of 160 with a dummy LPAR weighted at 10. That gives the real LPAR about 94% of the machine (160/(160+10)). You then talk about wanting to set it to 24 out of 26 MSUs. That comes to around 92%. Your kind of comparing apples to oranges. Besides, the software MSU figure is not the best thing to use for performance and capacity planning studies. It was designed by IBM solely as a way to keep software costs down. The software MSU to machine power ratio has been changing to the customers favor with each new hardware release. Tom Kelman Capacity Planning Commerce Bank, Kansas City -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Cobe Xu Sent: Thursday, November 04, 2010 11:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: CPU capping is not working for one Lpar only on CEC? Response to "what am I trying to do?", I'm working on a yearly performance & capacity review, and saw many many occasions that CPU overshoot the CAP line about 3%. And I try to figure this out. Thanks all, will check the PR/SM manual for the 1~3% saying. On Thu, Nov 4, 2010 at 11:49 PM, Al Sherkow wrote: > That 3% is not unexpected. WLM works with PR/SM to implement the cap. WLM > does the math and PR/SM does the actually "capping". If you read the PR/SM > planning guides (as Peter referenced) you'll see that PR/SM manages LPARs > to +- > 3 percent. > > I believe that WLM does the calculation to account for the possible MINUS > 3%. If > you were trying to cap at 100 MSUs and you only got 97 MSUs while paying > for > 100 you would be upset. If you pay for 100MSUs and get 3 Bonus MSUs you are > a > satisfied customer. (I chose 100 MSUs to make the math easy) > > Al Sherkow, I/S Management Strategies, Ltd. > Consulting Expertise on Capacity Planning, Performance Tuning, > WLC, LPARs, IRD and LCS Software > Seminars on IBM SW Pricing, LPARs, and IRD > Voice: +1 414 332-3062 > Web: www.sherkow.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- Cobe Xu Best Regards --- zOS Performance & Capacity Analyst E2E Performance Analyst Email: cob...@gmail.com --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping is not working for one Lpar only on CEC?
You might have more luck if you check for 3.6% rather than 3%. The 3.6% is valid up through z/Enterprise (see "Enforcement of processing weights" in any of the PR/SM Planning Guides). Regards, Don ** Don Deese, Computer Management Sciences, Inc. Voice: (804) 776-7109 Fax: (804) 776-7139 http://www.cpexpert.org ** At 12:43 PM 11/4/2010, you wrote: Response to "what am I trying to do?", I'm working on a yearly performance & capacity review, and saw many many occasions that CPU overshoot the CAP line about 3%. And I try to figure this out. Thanks all, will check the PR/SM manual for the 1~3% saying. On Thu, Nov 4, 2010 at 11:49 PM, Al Sherkow wrote: > That 3% is not unexpected. WLM works with PR/SM to implement the cap. WLM > does the math and PR/SM does the actually "capping". If you read the PR/SM > planning guides (as Peter referenced) you'll see that PR/SM manages LPARs > to +- > 3 percent. > > I believe that WLM does the calculation to account for the possible MINUS > 3%. If > you were trying to cap at 100 MSUs and you only got 97 MSUs while paying > for > 100 you would be upset. If you pay for 100MSUs and get 3 Bonus MSUs you are > a > satisfied customer. (I chose 100 MSUs to make the math easy) > > Al Sherkow, I/S Management Strategies, Ltd. > Consulting Expertise on Capacity Planning, Performance Tuning, > WLC, LPARs, IRD and LCS Software > Seminars on IBM SW Pricing, LPARs, and IRD > Voice: +1 414 332-3062 > Web: www.sherkow.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- Cobe Xu Best Regards --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping is not working for one Lpar only on CEC?
Response to "what am I trying to do?", I'm working on a yearly performance & capacity review, and saw many many occasions that CPU overshoot the CAP line about 3%. And I try to figure this out. Thanks all, will check the PR/SM manual for the 1~3% saying. On Thu, Nov 4, 2010 at 11:49 PM, Al Sherkow wrote: > That 3% is not unexpected. WLM works with PR/SM to implement the cap. WLM > does the math and PR/SM does the actually "capping". If you read the PR/SM > planning guides (as Peter referenced) you'll see that PR/SM manages LPARs > to +- > 3 percent. > > I believe that WLM does the calculation to account for the possible MINUS > 3%. If > you were trying to cap at 100 MSUs and you only got 97 MSUs while paying > for > 100 you would be upset. If you pay for 100MSUs and get 3 Bonus MSUs you are > a > satisfied customer. (I chose 100 MSUs to make the math easy) > > Al Sherkow, I/S Management Strategies, Ltd. > Consulting Expertise on Capacity Planning, Performance Tuning, > WLC, LPARs, IRD and LCS Software > Seminars on IBM SW Pricing, LPARs, and IRD > Voice: +1 414 332-3062 > Web: www.sherkow.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- Cobe Xu Best Regards --- zOS Performance & Capacity Analyst E2E Performance Analyst Email: cob...@gmail.com --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping is not working for one Lpar only on CEC?
That 3% is not unexpected. WLM works with PR/SM to implement the cap. WLM does the math and PR/SM does the actually "capping". If you read the PR/SM planning guides (as Peter referenced) you'll see that PR/SM manages LPARs to +- 3 percent. I believe that WLM does the calculation to account for the possible MINUS 3%. If you were trying to cap at 100 MSUs and you only got 97 MSUs while paying for 100 you would be upset. If you pay for 100MSUs and get 3 Bonus MSUs you are a satisfied customer. (I chose 100 MSUs to make the math easy) Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping is not working for one Lpar only on CEC?
Yes I like the questions of what are you trying to do? 24 of 26 MSUs seems odd to me. nor...@desertwiz.biz Sent from my Verizon Wireless BlackBerry -Original Message- From: Terry Draper Sender: IBM Mainframe Discussion List Date: Thu, 4 Nov 2010 11:09:33 To: Reply-To: IBM Mainframe Discussion List Subject: Re: CPU capping is not working for one Lpar only on CEC? I am not sure what type of capping you are trying to use. If you want to use hard capping then this will use the weights and it will give you 160/(160+10). This will not be exact. If you look at the PR/SM manual is is usually within 1% but can be over 3^% out. You talk about MSUs, which is soft capping and this uses the rolling 4 hour average. So until your 4 hour average goes over the define you can use over this number of MSUs. You cannot use both hard and soft capping. Looking at the report it says zero for your defined capacity MSUs. So it looks like you are not using soft capping. You have hardware capping set for yes. What are you trying to do. If you are managing the software costs then the MSU 4 hour rolling avaerage is appropriate. If you want to have a maximum capacity for a partition all teh time then you need hard capping. But remember there is a small percentage error rate on this. Terry Draper zSeries Performance Consultant w...@btopenworld.com mobile: +66 811431287 --- On Wed, 3/11/10, Cobe Xu wrote: From: Cobe Xu Subject: CPU capping is not working for one Lpar only on CEC? To: IBM-MAIN@bama.ua.edu Date: Wednesday, 3 November, 2010, 9:59 Hi list, We aim to cap the only active LPAR on the CEC(26 MSU) to 24 MSU. But, I'm a bit confuse when I checked the RMF CPU Activity report as below, which shows that with the interval, SYS2 was able to use up to 25 MSU. (Highlighted) So my questions are: 1. Is this because CPU capping is not working for only one active LPAR on the CEC? If it's the case, any reference? 2. Or, this is related to the WEIGHT value we used to CAP? in our case, we reference our CEC capacity is 26 MSU (about 171 MIPS), target to CAP 24 MSU (160 MIPS). . But, for client's sake, we use MIPS value as the WEIGHT,i.e 160. (as highlighted in the report). And, this mislead the Lpar scheduler that it is over 100% of the CEC. Thus, SYS2 can use as much as it needs. 3. Or any other posibility? Pls shed some light, thanks a lot! PAGE 2 z/OS V1R8 SYSTEM ID SYS2 START 08/17/2010-03.00.00 INTERVAL 000.59.59 RPT VERSION V1R8 RMF END 08/17/2010-04.00.00 CYCLE 0.100 SECONDS MVS PARTITION NAME SYS2 NUMBER OF PHYSICAL PROCESSORS 4 GROUP NAME N/A IMAGE CAPACITY 24 CP 2 LIMIT N/A NUMBER OF CONFIGURED PARTITIONS 5 ICF 2 WAIT COMPLETION NO DISPATCH INTERVAL DYNAMIC - PARTITION DATA - -- LOGICAL PARTITION PROCESSOR DATA -- -- AVERAGE PROCESSOR UTILIZATION PERCENTAGES -- MSU -CAPPING-- PROCESSOR- DISPATCH TIME DATA LOGICAL PROCESSORS --- PHYSICAL PROCESSORS --- NAME S WGT DEF ACT DEF WLM% NUM TYPE EFFECTIVE TOTAL EFFECTIVE TOTAL LPAR MGMT EFFECTIVE TOTAL SYS2 A 160 0 25 YES 0.0 2 CP 01.55.49.238 01.55.53.278 96.52 96.57 0.06 96.52 96.57 SYS6 A 10 0 0 YES 0.0 2 CP 00.00.00.000 00.00.00.000 0.00 0.00 0.00 0.00 0.00 *PHYSICAL* 00.00.01.367 0.02 0.02 -- -- -- TOTAL 01.55.49.238 01.55.54.645 0.08 96.52 96.59 CFP01AH2 A DED 1 ICF 00.59.59.655 00.59.59.725 99.99 99.99 0.00 50.00 50.00 CFP02AH2 A DED 1 ICF 00.59.59.666 00.59.59.708 99.99 99.99 0.00 50.00 50.00 *PHYSICAL* 00.00.00.422 0.01 0.01 -- -- -- TOTAL 01.59.59.321 01.59.59.855 0.01 99.99 100.0 SYS8 -- Cobe Xu Best Regards --- zOS Performance & Capacity Analyst E2E Performance Analyst Email: cob...@gmail.com --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to l
Re: CPU capping is not working for one Lpar only on CEC?
I am not sure what type of capping you are trying to use. If you want to use hard capping then this will use the weights and it will give you 160/(160+10). This will not be exact. If you look at the PR/SM manual is is usually within 1% but can be over 3^% out. You talk about MSUs, which is soft capping and this uses the rolling 4 hour average. So until your 4 hour average goes over the define you can use over this number of MSUs. You cannot use both hard and soft capping. Looking at the report it says zero for your defined capacity MSUs. So it looks like you are not using soft capping. You have hardware capping set for yes. What are you trying to do. If you are managing the software costs then the MSU 4 hour rolling avaerage is appropriate. If you want to have a maximum capacity for a partition all teh time then you need hard capping. But remember there is a small percentage error rate on this. Terry Draper zSeries Performance Consultant w...@btopenworld.com mobile: +66 811431287 --- On Wed, 3/11/10, Cobe Xu wrote: From: Cobe Xu Subject: CPU capping is not working for one Lpar only on CEC? To: IBM-MAIN@bama.ua.edu Date: Wednesday, 3 November, 2010, 9:59 Hi list, We aim to cap the only active LPAR on the CEC(26 MSU) to 24 MSU. But, I'm a bit confuse when I checked the RMF CPU Activity report as below, which shows that with the interval, SYS2 was able to use up to 25 MSU. (Highlighted) So my questions are: 1. Is this because CPU capping is not working for only one active LPAR on the CEC? If it's the case, any reference? 2. Or, this is related to the WEIGHT value we used to CAP? in our case, we reference our CEC capacity is 26 MSU (about 171 MIPS), target to CAP 24 MSU (160 MIPS). . But, for client's sake, we use MIPS value as the WEIGHT,i.e 160. (as highlighted in the report). And, this mislead the Lpar scheduler that it is over 100% of the CEC. Thus, SYS2 can use as much as it needs. 3. Or any other posibility? Pls shed some light, thanks a lot! PAGE 2 z/OS V1R8 SYSTEM ID SYS2 START 08/17/2010-03.00.00 INTERVAL 000.59.59 RPT VERSION V1R8 RMF END 08/17/2010-04.00.00 CYCLE 0.100 SECONDS MVS PARTITION NAME SYS2 NUMBER OF PHYSICAL PROCESSORS 4 GROUP NAME N/A IMAGE CAPACITY 24 CP 2 LIMIT N/A NUMBER OF CONFIGURED PARTITIONS 5 ICF 2 WAIT COMPLETION NO DISPATCH INTERVAL DYNAMIC - PARTITION DATA - -- LOGICAL PARTITION PROCESSOR DATA -- -- AVERAGE PROCESSOR UTILIZATION PERCENTAGES -- MSU -CAPPING-- PROCESSOR- DISPATCH TIME DATA LOGICAL PROCESSORS --- PHYSICAL PROCESSORS --- NAME S WGT DEF ACT DEF WLM% NUM TYPE EFFECTIVE TOTAL EFFECTIVE TOTAL LPAR MGMT EFFECTIVE TOTAL SYS2 A 160 0 25 YES 0.0 2 CP 01.55.49.238 01.55.53.278 96.52 96.57 0.06 96.52 96.57 SYS6 A 10 0 0 YES 0.0 2 CP 00.00.00.000 00.00.00.000 0.00 0.00 0.00 0.00 0.00 *PHYSICAL* 00.00.01.367 0.02 0.02 -- -- -- TOTAL 01.55.49.238 01.55.54.645 0.08 96.52 96.59 CFP01AH2 A DED 1 ICF 00.59.59.655 00.59.59.725 99.99 99.99 0.00 50.00 50.00 CFP02AH2 A DED 1 ICF 00.59.59.666 00.59.59.708 99.99 99.99 0.00 50.00 50.00 *PHYSICAL* 00.00.00.422 0.01 0.01 -- -- -- TOTAL 01.59.59.321 01.59.59.855 0.01 99.99 100.0 SYS8 -- Cobe Xu Best Regards --- zOS Performance & Capacity Analyst E2E Performance Analyst Email: cob...@gmail.com --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping is not working for one Lpar only on CEC?
Hi Tom, thanks for reply. yes, I know the weight value is absolutely different thing to MIPS... But fact is, we do use the *number* as "Initial Processing Weight". The calculation is: we need 24 MSU out of 26, the rate is about 93%. And in terms of MIPS, our 26 MSU is about 170 MIPS. So, we put the weight to SYS2 as 160. ( 170*93%), and the dummy LP weight 10. On Thu, Nov 4, 2010 at 2:15 AM, Kelman, Tom wrote: > Cobe, > > You do have me a little confused when you talk about capping at 24 MSUs > and setting the WEIGHT (which I assume is the LPAR weighting factor) to > 160. These are different. Also, the LPAR weighting factor is just a > relative number. It does not relate to MIPS. > > As far as the LPAR going over the cap in any given interval, that can > occur as long as the MSU four hour rolling average (4HRA) remains below > the cap. It is when the 4HRA hits the cap that you'll see the peaks > chopped off. Once the 4HRA falls below the cap the system can once > again spike up above that. If you have a cap set, and you are on > sub-capacity pricing, IBM's software charges for the sub-capacity priced > software will be based on the highest 4HRA for the month, but will never > exceed the cap. Actually, if you are not using sub-capacity pricing for > your software, I can't think of any reason to set a cap. > > Tom Kelman > Capacity Planning > Commerce Bank, Kansas City > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Cobe Xu > Sent: Wednesday, November 03, 2010 5:00 AM > To: IBM-MAIN@bama.ua.edu > Subject: CPU capping is not working for one Lpar only on CEC? > > Hi list, > We aim to cap the only active LPAR on the CEC(26 MSU) to 24 MSU. > But, I'm a bit confuse when I checked the RMF CPU Activity report as > below, > which shows that with the interval, SYS2 was able to use up to 25 MSU. > (Highlighted) > So my questions are: > 1. Is this because CPU capping is not working for only one active LPAR > on > the CEC? If it's the case, any reference? > 2. Or, this is related to the WEIGHT value we used to CAP? in our case, > we > reference our CEC capacity is 26 MSU (about 171 MIPS), target to CAP 24 > MSU > (160 MIPS). > . But, for client's sake, we use MIPS value as the WEIGHT,i.e 160. (as > highlighted in the report). And, this mislead the Lpar scheduler that it > is > over 100% of the CEC. Thus, > SYS2 can use as much as it needs. > 3. Or any other posibility? > Pls shed some light, thanks a lot! > > > > PAGE2 >z/OS V1R8SYSTEM ID SYS2 START > 08/17/2010-03.00.00 INTERVAL 000.59.59 > RPT VERSION V1R8 RMF END > 08/17/2010-04.00.00 CYCLE 0.100 SECONDS > > > MVS PARTITION NAMESYS2NUMBER OF PHYSICAL > PROCESSORS 4 GROUP NAME N/A > IMAGE CAPACITY 24 > CP2 LIMITN/A > NUMBER OF CONFIGURED PARTITIONS 5 > ICF 2 > WAIT COMPLETION > NO > > DISPATCH INTERVAL > DYNAMIC > > - PARTITION DATA - -- LOGICAL PARTITION > PROCESSOR > DATA -- -- AVERAGE PROCESSOR UTILIZATION PERCENTAGES -- > MSU -CAPPING-- PROCESSOR- DISPATCH > TIME > DATA LOGICAL PROCESSORS --- PHYSICAL PROCESSORS --- > NAME S WGT DEFACT DEF WLM% NUM TYPE EFFECTIVE > TOTAL EFFECTIVETOTAL LPAR MGMT EFFECTIVE TOTAL > SYS2 A 1600 25 YES0.02 CP01.55.49.238 > 01.55.53.278 96.5296.57 0.06 96.52 96.57 > SYS6 A100 0 YES0.02 CP00.00.00.000 > 00.00.00.0000.00 0.00 0.00 0.00 0.00 > *PHYSICAL* > 00.00.01.367 0.02 0.02 > > -- -- -- > TOTAL 01.55.49.238 > 01.55.54.645 0.08 96.52 96.59 > > > CFP01AH2 A DED1 ICF 00.59.59.655 > 00.59.59.725 99.9999.99 0.00 50.00 50.00 > CFP02AH2 A DED1 ICF 00.59.59.666 > 00.59.59.708 99.9999.99 0.00 50.00 50.00 > *PHYSICAL* > 00.00.00.422 0.01 0.01 > > --
Re: CPU capping is not working for one Lpar only on CEC?
That sounds interesting... I accept Tom's opinion that as long as the 4HRA is lower than the cap, some interval could be ran above the cap. However, in your scenario, if the 4HRA stabilze ABOVE the set defined capacity, it should not be more than 4 intervals, because the 5th interval will be the CAP value. back to our case, we'd like to cap at 24 MSU out of 26, however, when review CPU report, 80% of hourly intervals are about using 25 MSU..there's about 3% more to our expectation. On Thu, Nov 4, 2010 at 12:25 PM, Al Sherkow wrote: > It is possible for the 4HRA of an LPAR to go above the defined capacity > limit. This > is because the limit goes on typically after four hours of your workload > getting > bigger and bigger. Eventually the 4HRA exceeds the defined capacity and the > cap > goes on. As the four hour rolling average goes forward, the values from 4 > hours > ago, then 3h45m ago, then 3h30m ago are removed from the calculation of > that > average, and values at the capping level are going into the calculation, so > the > 4HRA may keep rising for a few intervals. It may even stabilize above the > set > defined capacity. Back in 2004 I coined the term "bonus MSUs" for these > MSUs > that are above the defined capacity value. When SCRT processes your SMF > data, > if the 4HRA in the data is above the defined capacity value SCRT ignores > those > "bonus MSUs". The Ts&Cs of sub-capacity WLC indicate you will not be > charged > for more MSUs than the Defined Capacity Value. > > Al Sherkow, I/S Management Strategies, Ltd. > Consulting Expertise on Capacity Planning, Performance Tuning, > WLC, LPARs, IRD and LCS Software > Seminars on IBM SW Pricing, LPARs, and IRD > Voice: +1 414 332-3062 > Web: www.sherkow.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- Cobe Xu Best Regards --- zOS Performance & Capacity Analyst E2E Performance Analyst Email: cob...@gmail.com --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping is not working for one Lpar only on CEC?
It is possible for the 4HRA of an LPAR to go above the defined capacity limit. This is because the limit goes on typically after four hours of your workload getting bigger and bigger. Eventually the 4HRA exceeds the defined capacity and the cap goes on. As the four hour rolling average goes forward, the values from 4 hours ago, then 3h45m ago, then 3h30m ago are removed from the calculation of that average, and values at the capping level are going into the calculation, so the 4HRA may keep rising for a few intervals. It may even stabilize above the set defined capacity. Back in 2004 I coined the term "bonus MSUs" for these MSUs that are above the defined capacity value. When SCRT processes your SMF data, if the 4HRA in the data is above the defined capacity value SCRT ignores those "bonus MSUs". The Ts&Cs of sub-capacity WLC indicate you will not be charged for more MSUs than the Defined Capacity Value. Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping is not working for one Lpar only on CEC?
Also see the PR/SM Planning Guide which has a good discussion called "Capping in a single logical partition". ---start quote In order to use capping for an LP on a CPC where there is a need for only one active LP using shared CPs, you must define and activate a second dummy LP. The dummy LP must also be defined as using shared CPs. The weights of the two LPs can be adjusted to attain the desired cap for the one LP that will actually be used. ---end quote thanks Peter On Wed, 3 Nov 2010 17:59:39 +0800, Cobe Xu wrote: >Hi list, >We aim to cap the only active LPAR on the CEC(26 MSU) to 24 MSU. >But, I'm a bit confuse when I checked the RMF CPU Activity report as below, >which shows that with the interval, SYS2 was able to use up to 25 MSU. >(Highlighted) >So my questions are: >1. Is this because CPU capping is not working for only one active LPAR on >the CEC? If it's the case, any reference? >2. Or, this is related to the WEIGHT value we used to CAP? in our case, we >reference our CEC capacity is 26 MSU (about 171 MIPS), target to CAP 24 MSU >(160 MIPS). >. But, for client's sake, we use MIPS value as the WEIGHT,i.e 160. (as >highlighted in the report). And, this mislead the Lpar scheduler that it is >over 100% of the CEC. Thus, > SYS2 can use as much as it needs. >3. Or any other posibility? >Pls shed some light, thanks a lot! > > > >PAGE2 >z/OS V1R8SYSTEM ID SYS2 START >08/17/2010-03.00.00 INTERVAL 000.59.59 > RPT VERSION V1R8 RMF END >08/17/2010-04.00.00 CYCLE 0.100 SECONDS > > >MVS PARTITION NAMESYS2NUMBER OF PHYSICAL >PROCESSORS 4 GROUP NAME N/A >IMAGE CAPACITY 24 >CP2 LIMITN/A >NUMBER OF CONFIGURED PARTITIONS 5 >ICF 2 >WAIT COMPLETION >NO > >DISPATCH INTERVAL >DYNAMIC > >- PARTITION DATA - -- LOGICAL PARTITION PROCESSOR >DATA -- -- AVERAGE PROCESSOR UTILIZATION PERCENTAGES -- > MSU -CAPPING-- PROCESSOR- DISPATCH TIME >DATA LOGICAL PROCESSORS --- PHYSICAL PROCESSORS --- >NAME S WGT DEFACT DEF WLM% NUM TYPE EFFECTIVE >TOTAL EFFECTIVETOTAL LPAR MGMT EFFECTIVE TOTAL >SYS2 A 1600 25 YES0.02 CP01.55.49.238 >01.55.53.278 96.5296.57 0.06 96.52 96.57 >SYS6 A100 0 YES0.02 CP00.00.00.000 >00.00.00.0000.00 0.00 0.00 0.00 0.00 >*PHYSICAL* >00.00.01.367 0.02 0.02 > > -- -- -- > TOTAL 01.55.49.238 >01.55.54.645 0.08 96.52 96.59 > > >CFP01AH2 A DED1 ICF 00.59.59.655 >00.59.59.725 99.9999.99 0.00 50.00 50.00 >CFP02AH2 A DED1 ICF 00.59.59.666 >00.59.59.708 99.9999.99 0.00 50.00 50.00 >*PHYSICAL* >00.00.00.422 0.01 0.01 > > -- -- -- > TOTAL 01.59.59.321 >01.59.59.855 0.01 99.99 100.0 > > >SYS8 >-- >Cobe Xu > >Best Regards >--- >zOS Performance & Capacity Analyst >E2E Performance Analyst >Email: cob...@gmail.com >--- > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping is not working for one Lpar only on CEC?
Cobe, You do have me a little confused when you talk about capping at 24 MSUs and setting the WEIGHT (which I assume is the LPAR weighting factor) to 160. These are different. Also, the LPAR weighting factor is just a relative number. It does not relate to MIPS. As far as the LPAR going over the cap in any given interval, that can occur as long as the MSU four hour rolling average (4HRA) remains below the cap. It is when the 4HRA hits the cap that you'll see the peaks chopped off. Once the 4HRA falls below the cap the system can once again spike up above that. If you have a cap set, and you are on sub-capacity pricing, IBM's software charges for the sub-capacity priced software will be based on the highest 4HRA for the month, but will never exceed the cap. Actually, if you are not using sub-capacity pricing for your software, I can't think of any reason to set a cap. Tom Kelman Capacity Planning Commerce Bank, Kansas City -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Cobe Xu Sent: Wednesday, November 03, 2010 5:00 AM To: IBM-MAIN@bama.ua.edu Subject: CPU capping is not working for one Lpar only on CEC? Hi list, We aim to cap the only active LPAR on the CEC(26 MSU) to 24 MSU. But, I'm a bit confuse when I checked the RMF CPU Activity report as below, which shows that with the interval, SYS2 was able to use up to 25 MSU. (Highlighted) So my questions are: 1. Is this because CPU capping is not working for only one active LPAR on the CEC? If it's the case, any reference? 2. Or, this is related to the WEIGHT value we used to CAP? in our case, we reference our CEC capacity is 26 MSU (about 171 MIPS), target to CAP 24 MSU (160 MIPS). . But, for client's sake, we use MIPS value as the WEIGHT,i.e 160. (as highlighted in the report). And, this mislead the Lpar scheduler that it is over 100% of the CEC. Thus, SYS2 can use as much as it needs. 3. Or any other posibility? Pls shed some light, thanks a lot! PAGE2 z/OS V1R8SYSTEM ID SYS2 START 08/17/2010-03.00.00 INTERVAL 000.59.59 RPT VERSION V1R8 RMF END 08/17/2010-04.00.00 CYCLE 0.100 SECONDS MVS PARTITION NAMESYS2NUMBER OF PHYSICAL PROCESSORS 4 GROUP NAME N/A IMAGE CAPACITY 24 CP2 LIMITN/A NUMBER OF CONFIGURED PARTITIONS 5 ICF 2 WAIT COMPLETION NO DISPATCH INTERVAL DYNAMIC - PARTITION DATA - -- LOGICAL PARTITION PROCESSOR DATA -- -- AVERAGE PROCESSOR UTILIZATION PERCENTAGES -- MSU -CAPPING-- PROCESSOR- DISPATCH TIME DATA LOGICAL PROCESSORS --- PHYSICAL PROCESSORS --- NAME S WGT DEFACT DEF WLM% NUM TYPE EFFECTIVE TOTAL EFFECTIVETOTAL LPAR MGMT EFFECTIVE TOTAL SYS2 A 1600 25 YES0.02 CP01.55.49.238 01.55.53.278 96.5296.57 0.06 96.52 96.57 SYS6 A100 0 YES0.02 CP00.00.00.000 00.00.00.0000.00 0.00 0.00 0.00 0.00 *PHYSICAL* 00.00.01.367 0.02 0.02 -- -- -- TOTAL 01.55.49.238 01.55.54.645 0.08 96.52 96.59 CFP01AH2 A DED1 ICF 00.59.59.655 00.59.59.725 99.9999.99 0.00 50.00 50.00 CFP02AH2 A DED1 ICF 00.59.59.666 00.59.59.708 99.9999.99 0.00 50.00 50.00 *PHYSICAL* 00.00.00.422 0.01 0.01 -- -- -- TOTAL 01.59.59.321 01.59.59.855 0.01 99.99 100.0 SYS8 -- Cobe Xu Best Regards --- zOS Performance & Capacity Analyst E2E Performance Analyst Email: cob...@gmail.com --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Se
CPU capping is not working for one Lpar only on CEC?
Hi list, We aim to cap the only active LPAR on the CEC(26 MSU) to 24 MSU. But, I'm a bit confuse when I checked the RMF CPU Activity report as below, which shows that with the interval, SYS2 was able to use up to 25 MSU. (Highlighted) So my questions are: 1. Is this because CPU capping is not working for only one active LPAR on the CEC? If it's the case, any reference? 2. Or, this is related to the WEIGHT value we used to CAP? in our case, we reference our CEC capacity is 26 MSU (about 171 MIPS), target to CAP 24 MSU (160 MIPS). . But, for client's sake, we use MIPS value as the WEIGHT,i.e 160. (as highlighted in the report). And, this mislead the Lpar scheduler that it is over 100% of the CEC. Thus, SYS2 can use as much as it needs. 3. Or any other posibility? Pls shed some light, thanks a lot! PAGE2 z/OS V1R8SYSTEM ID SYS2 START 08/17/2010-03.00.00 INTERVAL 000.59.59 RPT VERSION V1R8 RMF END 08/17/2010-04.00.00 CYCLE 0.100 SECONDS MVS PARTITION NAMESYS2NUMBER OF PHYSICAL PROCESSORS 4 GROUP NAME N/A IMAGE CAPACITY 24 CP2 LIMITN/A NUMBER OF CONFIGURED PARTITIONS 5 ICF 2 WAIT COMPLETION NO DISPATCH INTERVAL DYNAMIC - PARTITION DATA - -- LOGICAL PARTITION PROCESSOR DATA -- -- AVERAGE PROCESSOR UTILIZATION PERCENTAGES -- MSU -CAPPING-- PROCESSOR- DISPATCH TIME DATA LOGICAL PROCESSORS --- PHYSICAL PROCESSORS --- NAME S WGT DEFACT DEF WLM% NUM TYPE EFFECTIVE TOTAL EFFECTIVETOTAL LPAR MGMT EFFECTIVE TOTAL SYS2 A 1600 25 YES0.02 CP01.55.49.238 01.55.53.278 96.5296.57 0.06 96.52 96.57 SYS6 A100 0 YES0.02 CP00.00.00.000 00.00.00.0000.00 0.00 0.00 0.00 0.00 *PHYSICAL* 00.00.01.367 0.02 0.02 -- -- -- TOTAL 01.55.49.238 01.55.54.645 0.08 96.52 96.59 CFP01AH2 A DED1 ICF 00.59.59.655 00.59.59.725 99.9999.99 0.00 50.00 50.00 CFP02AH2 A DED1 ICF 00.59.59.666 00.59.59.708 99.9999.99 0.00 50.00 50.00 *PHYSICAL* 00.00.00.422 0.01 0.01 -- -- -- TOTAL 01.59.59.321 01.59.59.855 0.01 99.99 100.0 SYS8 -- Cobe Xu Best Regards --- zOS Performance & Capacity Analyst E2E Performance Analyst Email: cob...@gmail.com --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
