See inline.
Jeff Victor wrote:
John Beck wrote:
Brian> It appears the load values obtained within a local zone are
measured
Brian> across the whole system rather than for just the processes within
Brian> that local zone.
For all CPUs in whatever processor set sendmail is running in, which by
default would be the whole system.
Brian> ... that uses sendmail in multiple zones on the same system and
Brian> it uses the load metric for decisions about when to queue, when to
Brian> refuse connections, etc. Does the sendmail in a local zone get
its
Brian> LA metrics based on only its local zone or across the entire
system?
sendmail on Solaris (9 and later) uses pset_getloadavg(3C).
This is what I needed, to properly affect sendmail load averages, pools should
be used.
Brian> An how does that play with the use of FSS? If its for the entire
Brian> system, this would skew the behavior of how it would work in
zones.
I'll let someone more expert on the fair-share scheduler comment on that.
What do you mean by "how does that play with"? More configuration
details would help, e.g. what zones exist and what do they do.
Generally, the only effect FSS has on scheduling is to guarantee that
each workload (project or zone) receives its assigned minimum portion of
the CPU cycles in that processor set.
In this case, the only effect FSS will have is to assign fewer time
slices to sendmail *if* these two conditions exist:
1) CPU utilization of the processor set is high
2) the scheduling entity (project or zone) in which sendmail operates is
using a larger portion of available CPU cycles than you have assigned to it
The first step is getting access to the hardware, which is in the works...
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.
Brian> Also, would pools with processor sets make this better or worse?
I would suspect better, since only CPUs in that processor set would be
counted.
I suspected that the load averages were based on processor sets, but
thanks for the confirmation. I had actually considered a hybrid situation
with the customer that would create 2 pools, one zone in one pool, and the
other 2 zones in the other pool and each getting 50% of the pool via FSS.
This may work, however the problem of one zone using more than its minimum
of 50% (lets say it is using 99.9%) will most likely affect the load average
as seen by the other zone, thereby possibly causing connection refusals.
So it looks like creating 3 separate pools is the only viable solution.
It would be nice if there could be some way to determine in the load average
only the amount of load that is contributed by its own zone as compared to its
minimum CPU allocation rather than that of all the zones sharing a processor
set.
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
