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)
