Getting to understand VM SHARE settings is a science - and a bit of guess work - there is no doubt!
In my example, I have a multiprocessing Linux server with 2 vcpus. Uncapped, it can get 200% total CPU if it ran flat out and there were no constraints on the whole z. The whole z LPAR has 11 IFLs on it. So we need to cap that puppy to not go over 25% total CPU. The calculation would be: 25% / 11 = 2.3% - thus a SET SHARE puppy REL 200 ABS 2.3% LIMITHARD did the trick The absolute SHARE is based on the number of physical processors on the system. Granted Kris did give a good point for workload that is uniprocessor based so that if your workload is biased toward only using 1 vcpu, then you would only get HALF of the full capacity because it won't/can't use the second vcpu. This works for us - we use the capping for poor behaving test servers and the cpu never gets over 25%. The whole concept takes getting used to. It is often not the easiest to grasp that the server's "total" cpu capacity is based on 100% * vcpus. If that 2 vcpu system is running uncapped and flat out, the total of the whole z would be 200 / 1100 which would be 18.18% - but that is of the WHOLE z box, not of it's own total CPU. It is really consuming 2 complete IFLs all by itself or 200% of it's total cpu capacity. I guess you can look at it from the entire z capacity standpoint that it is using 18.18% of the whole box. So we would then have to cap it to only use 2.3% of the total box cpu capacity - which surprisingly is 25.3% total CPU. Fun stuff, ain't it? This is why Bill Bitner loves his job! :-) JimV On 8/6/07, Stracka, James (GTI) <[EMAIL PROTECTED]> wrote: > > OK, now you confused me. By virtue of the fact that it has 2 VCPUs in an > 11 RCPU environment, would it not automatically be capped at 18.18%because it > cannot get more than two CPUs? > > Or, did you mean 2.5% and not 25%? > > -----Original Message----- > *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On > Behalf Of *James Vincent > *Sent:* Friday, August 03, 2007 9:08 PM > *To:* IBMVM@LISTSERV.UARK.EDU > *Subject:* Re: SET SHARE RELATIVE > > I certainly did not want to cause confusion - this is why I said " There > is actually more science..." I was passing on what we learned through > trial, error and then a phone call. And blast it, you are indeed correct > Kris. > > On a system with 11 IFLs and a 2 vcpu guest that we needed to cap at 25%, > we had to set its share as SET SHARE RELATIVE 200 ABSOLUTE 2.3%LIMITHARD. > This is the only way we could successfully get the server to not > go over 25% cpu total. > > In our case, the linux guests are all multi-processor apps and none are > multi-vcpu uniprocessor apps so the behavior was as expected, the apps got > up to 25% (and not 12.5% if they were uniprocessing) > > The answer is I guess "It Depends" since you will really need to know your > applications and how they run in order to set the SHARE the way you really > need it. I was trying to keep it "simple" - ha! > > Jim > > On 8/3/07, Kris Buelens <[EMAIL PROTECTED]> wrote: > > > > Jim, I'd say your append can introduce confusion. > > > > The vcpus still count for absolute shares. But, indeed, the number of > > real CPUs come into account: the % written on the SET SHAER command is > > expressed as a % of the whole system. > > If you have 10 CPU's, a SET SHARE ABS 5% LIMITHARD means that a > > uniprocessor guest can consume 50% of one CPU. If the guest has two virtual > > processors, each one can consume 25% at most. This is very important if > > this guest would run one heavy uniprocessing task, this task will have a > > hard time to get more than 25% of a CPU. We learned this the hard way when > > installing a 6 engine 9672 ages ago (our heavy process was a VM DB2 server) > > > ------------------------------ > This message w/attachments (message) may be privileged, confidential or > proprietary, and if you are not an intended recipient, please notify the > sender, do not use or share it and delete it. Unless specifically indicated, > this message is not an offer to sell or a solicitation of any investment > products or other financial product or service, an official confirmation of > any transaction, or an official statement of Merrill Lynch. Subject to > applicable law, Merrill Lynch may monitor, review and retain > e-communications (EC) traveling through its networks/systems. The laws of > the country of each sender/recipient may impact the handling of EC, and EC > may be archived, supervised and produced in countries other than the country > in which you are located. This message cannot be guaranteed to be secure or > error-free. This message is subject to terms available at the following > link: http://www.ml.com/e-communications_terms/. By messaging with Merrill > Lynch you consent to the foregoing. > ------------------------------ > >
