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 shares
taking into account the share in the global zone.  Since there's not much
going on in the global zone, we can just as easy make the shares 2, 1, 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 allocation,
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.

See 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 example
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 that
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 determine
if the queue/refuse connection thresholds are met.

How does FSS make that situation worse? The misleading [1] 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 friend. :-)

[1] "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 associated

zones-discuss mailing list

Reply via email to