I gave a simplistic example.  In reality they have systems that are
mostly idle and want to be able to allocate fractional CPU values
to zones so for that FSS would be ideal.  Using pools/psrsets the
smallest value you can allocate is 1, however thats not realistic
for a production environment - you need to allocation no less than
2 in case one fails.  So allocating 2 cpus to a zone that only really
requires quarter or tenth of a cpu is wasteful.  Even using dynamic
allocation requires that you allocate at least one full cpu to the zone.

I think it is a bug that the load of zone A affects the reported load
in zone B thereby causing a process in zone B (sendmail) to make bad
decisions that are based on perceived load average.

Michael Barto wrote:
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).


(1) http://www.logiqwest.com/dataCenter/Demos/RunBooks/Zones/enableZoneVariableCPUs.html
and compare it with
(2) http://www.logiqwest.com/dataCenter/Demos/RunBooks/Zones/enableZoneFixedCPUs.html

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 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 http://www.logiqwest.com/dataCenter/Demos/RunBooks/Zones/enableZoneFairShareCPUs.html 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