Remember that FSS is designed to provide a minimum, but not a max.
Depending on CPU use by other threads in the class, a given thread may
get more than it's alloted CPU shares, but it will never get less.
/jim
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
with.
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
