The problem is that using CPU's to allocate resources is defined as a
fixed interger value and you cannot split the resource up down below
that unit. If you have 101 CPU's on your server then that maybe how it
can be done.|
The other ways to do zone CPU resource allocation are (1) Enable a Zone
to Use a Fixed Number of CPS's or (2) Enable Zone to use a variable
number of CPU's. I am not really clear why this is such a issue, but I
think the variable method might be what you want. A variable processor
set is defined when the maximum and minimum number of processors are
different value in the set. The daemon poold will shuffle
CPUs from one zone to another and the default set as demand varies.
(see the diagram in the first link).
and compare it with
In the variable set, the CPU's are allocated by from a default pool set
as required but never do exceed that number. If there is a way to stop
allocation at the application level for sendmail, then that is really
not a zone resource issue.
Brian Kolaci wrote:
Yes, but the
amount used by the global zone should be negligible as
the policy is that no applications will be deployed in the global zone
if there are any local zones.
I explained this to the customer yesterday already. In reality if
we divide the shares up with 50, 25, 25 so there would be 101 total
taking into account the share in the global zone. Since there's not
going on in the global zone, we can just as easy make the shares 2, 1,
to get the same result. I just used the other numbers as an example.
But again, this is off topic. FSS isn't where the issue is. Its just
the perception it gives that since it guarantees minimum CPU
however even though the zone is idle, the load average may and probably
will exceed the threshold setup in sendmail therefore even an idle zone
would reject incoming connections due to load generated by other zones.
Thats how I came to the conclusion with the current implementation of
getting load averages coming from processor sets rather than the load
running within a zone prohibits the sole use of FSS to consolidate
sendmail servers. The only feasible solution is to use pools/psrsets
and make sure each zone is allocated a proper amount of CPU. That way
its load average algorithm will continue to work.
Michael Barto wrote:
Fair Share is based on count value kind of
like a percentage but divided by the total. For you could use values
50, 25, 25 to meet your requirements which adds up to 100. But remember
that the Global zone needs some cycle (the default is 1 for the global
zone), so you should probably set up 49, 25, and 25.
which is some documentation that we are developing for setting up Fair
Share in Solaris Zones.
Brian Kolaci wrote:
Jeff Victor wrote:
Brian Kolaci wrote:
I've been discussing about how to chop up a machine. An possible
configuration would have 8 cpus, 3 local zones. They would possibly be
divided up as 50%, 25% and 25%. Its clear how to do this with pools,
however FSS is a great fit for when a zone may need more CPU than whats
available in the pool/psrset. The problem with FSS in this case is
if one zone is mostly idle and all the other zones are busy, the zone
that is idle will get a load average much higher than its really using
which can skew the calculations use by the sendmail process to
if the queue/refuse connection thresholds are met.
How does FSS make that situation worse? The misleading  load avg is
not affected by FSS, which is merely enforcing the minimum CPU-power
portions that you chose. If they are inappropriate, prctl can be your
 "misleading" for this situation, not so for others.
I guess what I mean is that with FSS, people get the impression
that they are dividing the resources fairly among the zones but the
misleading load average tells processes that they're already using
all or more than their share already. Agreed, its not really a problem
of FSS, but that the load averages reported in a zone do not reflect
what it actually is in the zone, but of the processor set it is
16458 Bolsa Chica Street, # 15
Huntington Beach, CA 92649
Tel: 714 377 3705
Fax: 714 840 3937
Cell: 714 883 1949
|'tis a gift to be
| This e-mail may contain
proprietary information and should be treated as confidential.