Re: LPAR performance questions ?
On Thu, 25 Jan 2007 21:56:09 +, Ted MacNEIL [EMAIL PROTECTED] wrote: PS: I am not really enamoured of the I'm too lazy... comment. This list works better if the posters do their homework. Totally uncalled for comment - *especially* considering the person it was directed to. Ed used those word but it isn't really a matter of being lazy. This wasn't a whats the operator command to do xyx? type of question. ROTs are seldom documented in manuals and this particular one really does depend. This list also works better when people post replies to questions when they are sure of the answer instead of posting erroneous information from memory or obsolete information. But I don't think you've ever done that, have you? -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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: LPAR performance questions ?
On Wed, 2007-01-24 at 22:47 -0800, Edward Jaffe wrote: That leaves 2 engines for the other 5 LPARs - with at least one having two logical engines defined. Makes for a bad logical~physical ratio. What is the highest recommended ratio on modern machines? Pick a (low) number. For me 2.5:1 would be where things start to get rubbery. Don't know what the highest recommended ratio would be - especially on modern machines. Keeping a eye on capture ratio is always worthwhile. There are other issues of course - GRS ring at high ratios is death. Ditto for sysplex with CF LPARs rather than true (dedicated) CF engines. And yes, people still consider it an option. Shane ... -- 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: LPAR performance questions ?
My two cents: I agree with Shane. The rule of thumb used to be not to go over 2:1 logical to physical on a CEC, when adding up all of the logicals for all the lpars, but I don't know what's recommended now either. At the 2:1 ratio, we saw the performance elbow on 9672 and 2064 systems. 2084 and 2094 seem to have done something (cp speed? Better pr/sm logic?) that makes it more like 2.5:1 at crunch time. We've run 2094 systems routinely at 3.5:1, which is fine up until the CEC is around 85% physical busy (1.2% lpar management time). After that, it's got to come down to something closer to 2.5:1 (0.6% lpar management time) or engines start getting real short. IRD's cpu vary seems to do a good job at staying on top of this until the CEC gets past 99.7% physical busy. And it's still true that you can get best utilization from a CEC that's 100% busy with lpars pushing for more, by squaring the box so the weights and logical cp assignments match up to almost simulate a dedicated CP configuration. Of course, if you have lpars that are sized for anything smaller than one engine, you wouldn't be able to get away with this anymore. I'm sure some of you have had the same experiences, when the legitimate workload overruns the capacity of the box and there's no money allocation for upgrades coming any time soon, and you have to go back to simulating basic or dedicated cp mode. Best regards, Gary Diehl -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shane Subject: Re: LPAR performance questions ? Pick a (low) number. For me 2.5:1 would be where things start to get rubbery. -- 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: LPAR performance questions ?
So the story hasn't really changed. It's make it as low as you can and YMMV. It also depends on the activity of the LPARs. Inactive or low usage ones can change the ratio upward with little or no impact (the YMMV part). PS: I am not really enamoured of the I'm too lazy... comment. This list works better if the posters do their homework. . Questions? Concerns? (Screams of Outrage?) -- 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: LPAR performance questions ?
Shane wrote: That leaves 2 engines for the other 5 LPARs - with at least one having two logical engines defined. Makes for a bad logical~physical ratio. What is the highest recommended ratio on modern machines? (Too lazy to do the research. Figured you'd know off the top.) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.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
Re: LPAR performance questions ?
On Sat, 20 Jan 2007 09:19:50 -0600, Rick Fochtman [EMAIL PROTECTED] wrote: I'm a firm believer in separating TEST workloads from PROD workloads and keeping each in its own LPAR. This way, a run-away CICS transaction in a test CICS can't have anywhere near as much impact on the overall PROD workload. Again, YMMV. Personal preference. Mine is to put test workloads on the same LPAR as production and keep the test LPARs for sysprog work. Let WLM manage the resources on the prod LPAR and give preference to the PROD work. There are advantages and disadvantages to either approach. As you said, YMMV. -- Tom Marchant -- 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: LPAR performance questions ?
Hi, We have the following IBM box : *IBM z890-2086-A04 Model 6260 with SN 2549A ; with zOS 1.7. in 64 bit mode ; z990 Exploitation Feature (there are two IFL in this configuration). We have 5 LPAR's defined on this box and 1 Linux Lpar. None of these LPAR's are capped and we are running at 150% CPU busy on the Production Lpar. Questions : 1. Would these different LPAR's not effect each other 2. Why do I need 2 test LPAR's in this setup 3. Should it not be more beneficial to remove some of these LPAR's. So instead of 5 , I rather define 3. Some people are arguing that we should move some of the Test CICS'se , off the Prod LPAR and into a Test LPAR. I prefer to run less LPAR's and keep everything on the Prod Lpar. What do you think ? Anton -- 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: LPAR performance questions ?
---snip- Hi, We have the following IBM box : *IBM z890-2086-A04 Model 6260 with SN 2549A ; with zOS 1.7. in 64 bit mode ; z990 Exploitation Feature (there are two IFL in this configuration). We have 5 LPAR's defined on this box and 1 Linux Lpar. None of these LPAR's are capped and we are running at 150% CPU busy on the Production Lpar. Questions : 1. Would these different LPAR's not effect each other ---unsnip-- Yes, the LPARs will affect each other. There's only so much CPU service in the pie, no matter how you slice it. Dividing it up 5 ways instead of three means that each LPAR could get a smaller slice. Plus you have the overhead difference between 5 LPARs and 3 LPARs. ---snip- 2. Why do I need 2 test LPAR's in this setup ---unsnip-- I know of no technical reason; perhaps there are political or business reasons in your shop. ---snip- 3. Should it not be more beneficial to remove some of these LPAR's. So instead of 5 , I rather define 3. -unsnip I would recommend removing 2 LPARs and consolidating workloads. But I'm thinking from a technical standpoint; you may have other considerations, as in point 2. YMMV. Beware of possible turf wars within your shop. You may also have to rethink LPAR weighting factors. snip Some people are arguing that we should move some of the Test CICS'se , off the Prod LPAR and into a Test LPAR. I prefer to run less LPAR's and keep everything on the Prod Lpar. What do you think ? unsnip- I'm a firm believer in separating TEST workloads from PROD workloads and keeping each in its own LPAR. This way, a run-away CICS transaction in a test CICS can't have anywhere near as much impact on the overall PROD workload. Again, YMMV. -- 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: LPAR performance questions ?
In a message dated 1/20/2007 9:21:05 A.M. Central Standard Time, [EMAIL PROTECTED] writes: I would recommend removing 2 LPARs and consolidating workloads. But I'm thinking from a technical standpoint; you may have other considerations, as in point 2. YMMV. Beware of possible turf wars within your shop. You may also have to rethink LPAR weighting factors. I agree and would CAP the Test and Development LPARs significantly. Again assumptions are made as to business model. I've seen financial institutions where Production and Test were mandated electronically separate and developmental environments where 'testing is our priority'. Further at 150% utilization WLM doesn't function well. I'll plug Cheryl's Goal Tender software(_www.watsonwalker.com_ (http://www.watsonwalker.com) ) to see how your goals are fairing against reality. It may be that you're only buying time for the next upgrade, but at least you'll have corroboration/justification. -- 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: LPAR performance questions ?
Hi, One more question : If the LINUX Lpar is running at 110% busy, does this LPAR take power away from the 2 physical engines ? Anton -- 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: LPAR performance questions ?
In a message dated 1/20/2007 12:13:16 P.M. Central Standard Time, [EMAIL PROTECTED] writes: One more question : If the LINUX Lpar is running at 110% busy, does this LPAR take power away from the 2 physical engines ? Yes, but only due to the fact that it's an LPAR not that it's running at 110% busy. IBM has worked on the state space switching algorithms in uCode and it's gotten better over the years but it's still overhead and still hard to measure precisely without large expenditures in hardware and people. Remember one large shop gave a user benchmark(late eighties) with and without PR/SM and it was near 30% overhead on a 400J. -- 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: LPAR performance questions ?
Ed, Are you sure about this because I was led to believe that the LINUX LPAR runs off it's own processors ? Anton Ed Finnell wrote: In a message dated 1/20/2007 12:13:16 P.M. Central Standard Time, [EMAIL PROTECTED] writes: One more question : If the LINUX Lpar is running at 110% busy, does this LPAR take power away from the 2 physical engines ? Yes, but only due to the fact that it's an LPAR not that it's running at 110% busy. IBM has worked on the state space switching algorithms in uCode and it's gotten better over the years but it's still overhead and still hard to measure precisely without large expenditures in hardware and people. Remember one large shop gave a user benchmark(late eighties) with and without PR/SM and it was near 30% overhead on a 400J. -- 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 -- 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: LPAR performance questions ?
On Sat, 2007-01-20 at 15:04 -0500, Ed Finnell wrote: Remember one large shop gave a user benchmark(late eighties) with and without PR/SM and it was near 30% overhead on a 400J. Muggs- they should have used Amdahl kit, then they could have benefited from MDF :o) Anyway back to Antons questions. Presumably the Linux LPAR is running on the 2 IFLs. It is not a consideration in performance terms at 110%. To all intents and purposes it is running dedicated (unless there is a VM LPAR we don't know about lurking around), and below capacity. That leaves 2 engines for the other 5 LPARs - with at least one having two logical engines defined. Makes for a bad logical~physical ratio. So ... as the others have said, get the number of MVS LPARs down. Shane ... -- 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: LPAR performance questions ?
In a message dated 1/20/2007 2:18:42 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Are you sure about this because I was led to believe that the LINUX LPAR runs off it's own processors ? I'd have to have more information. If it's running on dedicated IFL's I'll retract. If it's running on own LPAR or under VM LPAR then I'm sure. Don't run SHADOW at all. -- 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
