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 a...@sherkow.com 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 TsCs 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?
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 thomas.kel...@commercebank.comwrote: 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
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 cob...@gmail.com wrote: From: Cobe Xu cob...@gmail.com 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
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 w...@btopenworld.com Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Date: Thu, 4 Nov 2010 11:09:33 To: IBM-MAIN@bama.ua.edu Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 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 cob...@gmail.com wrote: From: Cobe Xu cob...@gmail.com 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
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?
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 a...@sherkow.com 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?
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 a...@sherkow.com 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?
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 a...@sherkow.com 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?
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
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
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 Secure Email Message Center at https
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 cob...@gmail.com 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?
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 TsCs 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
cpu capping question
Hi all, I have following question on CPU hard capping LPAR1 initial capping=No CPU weight 80 = 800mips LPAR2 initial capping=Yes CPU weight 20 = 200mips assume CPU has 1000mips my question is, for LPAR2 the maximum CPU utilization is 200 mips with hard capping but how about LPAR1? the maximum CPU utilization is 800mips or more than 800mips with initial capping=no? I knew that soft capping is more suitable for this case with defined capacity weight. any help will be appreciated -- 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 question
LPAR1 is not capped. It can take 100% of the CPU if LPAR 2 is idle and it needs it. If LPAR 2 is active, then LPAR 1 can take up to 80% and LPAR 2 20%. If LPAR 1 is idle, then LPAR 2 can take up to the hard cap value. You did not mention the capping value for LPAR2. If, for example, you have hard capped LPAR 2 at, say, 150 mips, then it can never take more than that. So, LPAR 1 could take 85% and LPAR 2 15% if both are competing for the CPU. I assume you really meant to say MSU's instead of MIPS. MIPS is not a valid metric in this context. Hard cap, soft cap, and weights are all different controls, but all three need be considered to manage your machine. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: Wednesday, February 10, 2010 8:59 AM To: IBM-MAIN@bama.ua.edu Subject: cpu capping question Hi all, I have following question on CPU hard capping LPAR1 initial capping=No CPU weight 80 = 800mips LPAR2 initial capping=Yes CPU weight 20 = 200mips assume CPU has 1000mips my question is, for LPAR2 the maximum CPU utilization is 200 mips with hard capping but how about LPAR1? the maximum CPU utilization is 800mips or more than 800mips with initial capping=no? I knew that soft capping is more suitable for this case with defined capacity weight. any help will be appreciated NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 question
Hi Merritt, If LPAR1 (our production) is not capped but LPAR 2 (development) is active (assume the weight=20% or 200 mips, it only utilize 100 mips at night), Can LPAR1 utilize 900 mips at night ??? 2010/2/10 Hal Merritt hmerr...@jackhenry.com: LPAR1 is not capped. It can take 100% of the CPU if LPAR 2 is idle and it needs it. If LPAR 2 is active, then LPAR 1 can take up to 80% and LPAR 2 20%. If LPAR 1 is idle, then LPAR 2 can take up to the hard cap value. You did not mention the capping value for LPAR2. If, for example, you have hard capped LPAR 2 at, say, 150 mips, then it can never take more than that. So, LPAR 1 could take 85% and LPAR 2 15% if both are competing for the CPU. I assume you really meant to say MSU's instead of MIPS. MIPS is not a valid metric in this context. Hard cap, soft cap, and weights are all different controls, but all three need be considered to manage your machine. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: Wednesday, February 10, 2010 8:59 AM To: IBM-MAIN@bama.ua.edu Subject: cpu capping question Hi all, I have following question on CPU hard capping LPAR1 initial capping=No CPU weight 80 = 800mips LPAR2 initial capping=Yes CPU weight 20 = 200mips assume CPU has 1000mips my question is, for LPAR2 the maximum CPU utilization is 200 mips with hard capping but how about LPAR1? the maximum CPU utilization is 800mips or more than 800mips with initial capping=no? I knew that soft capping is more suitable for this case with defined capacity weight. any help will be appreciated NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 question
Again, the weights have nothing to do with capping. But to answer your question: yes. Now, be careful. If LPAR 2 is hard capped at 200 MSU and is using 200 MSU, then SDSF will report 100% CPU utilization. In your scenario, you could hard cap LPAR 2 at 200 MSU and set the weights to 90/10. LPAR 2 could then use up to 200 MSU, but would be given no less than 100 MSU if LPAR 1 is active. LPAR 1 could use all 1000 MSU if LPAR 2 is idle, or no less than 900 MSU if LPAR 2 is active. Perhaps your business may be better served with a 20 MSU cap and weights 0f 95/5. That is, LPAR 2 could never use more than 20 MSU, but LPAR 1 could take 950 MSU if needed. Again, LPAR 1 could take all 1000 MSU if LPAR 2 is idle. HTH and good luck -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: Wednesday, February 10, 2010 9:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: cpu capping question Hi Merritt, If LPAR1 (our production) is not capped but LPAR 2 (development) is active (assume the weight=20% or 200 mips, it only utilize 100 mips at night), Can LPAR1 utilize 900 mips at night ??? 2010/2/10 Hal Merritt hmerr...@jackhenry.com: LPAR1 is not capped. It can take 100% of the CPU if LPAR 2 is idle and it needs it. If LPAR 2 is active, then LPAR 1 can take up to 80% and LPAR 2 20%. If LPAR 1 is idle, then LPAR 2 can take up to the hard cap value. You did not mention the capping value for LPAR2. If, for example, you have hard capped LPAR 2 at, say, 150 mips, then it can never take more than that. So, LPAR 1 could take 85% and LPAR 2 15% if both are competing for the CPU. I assume you really meant to say MSU's instead of MIPS. MIPS is not a valid metric in this context. Hard cap, soft cap, and weights are all different controls, but all three need be considered to manage your machine. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: Wednesday, February 10, 2010 8:59 AM To: IBM-MAIN@bama.ua.edu Subject: cpu capping question Hi all, I have following question on CPU hard capping LPAR1 initial capping=No CPU weight 80 = 800mips LPAR2 initial capping=Yes CPU weight 20 = 200mips assume CPU has 1000mips my question is, for LPAR2 the maximum CPU utilization is 200 mips with hard capping but how about LPAR1? the maximum CPU utilization is 800mips or more than 800mips with initial capping=no? I knew that soft capping is more suitable for this case with defined capacity weight. any help will be appreciated NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 question
Tommy -- Yes, LPAR 1 has access to the capacity that LPAR 2 is not using. The cap on LPAR2 is a limit only on LPAR2's use of your capacity. 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
From: R.S. [EMAIL PROTECTED] HARD capping is NOT disruptive. It does require neither LPAR deactivate, nor IPL. AFAIK soft capping *does* prevent CPC to exceed defined capacity. It allows for *temporary* peaks, but you pay for 4-hr rolling average. Radoslaw, you are right in both cases. I'll try the HARD capping solution. Thanks Walter Marguccio z/OS Systems Programmer Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping
or look at a powerful product to control your White Space MSU,s on website www.zcostmanagement.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CPU capping
Hello list, within the Trybuy agreement with IBM, we temporarily enhanced our z890 from capacity setting 230 to 470. Needless to say that everybody within our organization and the customers, too, were impressed by the improved response time. But time has come to get back to our original model, and I'm looking for a way to make this move as smoothly as possible. I'm thinking to gradually capping the CPs of our PROD LPAR, but I'm not sure whether a SOFT capping of HARD capping might help. From what I understood by RTFM, SOFT capping does not prevent the CPC to exceed the defined capacity. On the other hand, HARD capping would require a IPL, since the LPAR's profile needs to be updated and a deactivate/activate is needed. I'd avoid this, if possible. Anyone faced this already in the past and found out how to go back to a slower CPC in a less drastic way? Walter Marguccio z/OS Systems Programmer Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping
Walter Marguccio wrote: Hello list, within the Trybuy agreement with IBM, we temporarily enhanced our z890 from capacity setting 230 to 470. Needless to say that everybody within our organization and the customers, too, were impressed by the improved response time. But time has come to get back to our original model, and I'm looking for a way to make this move as smoothly as possible. I'm thinking to gradually capping the CPs of our PROD LPAR, but I'm not sure whether a SOFT capping of HARD capping might help. From what I understood by RTFM, SOFT capping does not prevent the CPC to exceed the defined capacity. On the other hand, HARD capping would require a IPL, since the LPAR's profile needs to be updated and a deactivate/activate is needed. I'd avoid this, if possible. HARD capping is NOT disruptive. It does require neither LPAR deactivate, nor IPL. AFAIK soft capping *does* prevent CPC to exceed defined capacity. It allows for *temporary* peaks, but you pay for 4-hr rolling average. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping
within the Trybuy agreement with IBM, we temporarily enhanced our z890 from capacity setting 230 to 470. Needless to say that everybody within our organization and the customers, too, were impressed by the improved response time. Walter - I'm guessing its not too much of a stretch to think the IBM marketing guys would say your missing the point - Its a Try BUY agreement. Don't turn it off - just buy it! ;-) I don't like the gradual idea... just extends the pain... like slowly turning the screws on the rack. If you have to turn it off, just chop away and make sure the management fellow who signed the agreement sends the change notification out. Jeffrey Deaver, Engineer Systems Engineering [EMAIL PROTECTED] 651-665-4231(v) 651-610-7670(p) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU capping
On Fri, 13 Apr 2007 05:41:07 -0700, Walter Marguccio [EMAIL PROTECTED] wrote: But time has come to get back to our original model, and I'm looking for a way to make this move as smoothly as possible. I'm thinking to gradually capping the CPs of our PROD LPAR, create a CF lpar , put it in dyndisp=no and increase the weight by some x % each day (This is the way i cap my boxes ) Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
