I think you've captured the issues well here.

I do think that regardless of FSS preventing one zone from
consuming all the CPU, sendmail will still need to be able
to throttle itself until an SA comes in to re-provision the
resources and give the zone more CPU.  The throttling can
be turned off, but its there for good reason.  One would think
that if a sendmail is "configured properly" and the load average
threshold is set properly then the zone shouldn't exceed the
expected load within its zone so as to not affect the other zones.
But human error is always evident.

Jeff Victor wrote:
This thread confused me at first, so I'll try to re-phrase the core issues to check my current understanding. One issue is a general piece of confusion that Solaris hands us, the other is a conflict of assumptions.

1) pset_getloadavg() (mentioned earlier in this thread) reports the load avg of the processor set in which the zone resides, not the number of runnable proc's in the zone. Using vmstat yields the same result. This is confusing enough that I would call it a bug. I can't find a CR on this, but if others agree that this should be improved, I will file the CR.

2) The other issue involves a programmer's attempt to manage a workload based on an assumption which has historically been correct, but is not safe to make if the workload is running in a zone. Evidently, sendmail uses the load avg to decide when to do its work. Sans FSS, sendmail is doing what it has been told to do, and is, arguably, doing the right thing in that sendmail is throttling itself because the CPUs in that pset are very busy, albeit in other zones.

You can use FSS to make CPU cycles available to sendmail, but if it doesn't choose to use them, it won't. (Very much like "you can lead a horse to water, but you can't make it drink.")

What to do? If you use FSS to prevent sendmail from consuming all the CPU cycles, then you don't need to use sendmail's own self-throttling mechanism. Is it possible to turn it off, or to raise the load-avg-threshold so high that it never throttles itself?

Brian Kolaci wrote:

Thanks, but I think we're getting off topic.
I know how FSS works and what its intended for, however the
issue isn't with FSS but more that the load averages as seen
within a zone are not based on the loads in the zone, but
rather to the pool to which the zone is associated with.

FSS isn't the culprit here, sorry I made it sound that way.
So if you don't enable pools (so there's one shared pool) and
you use FSS to divide up the resources, then sendmail within one
of the local zones makes decisions based on the load average of
the processor set (which is the load of all zones put together)
rather than just the workload of the zone.  So if another zone
consumes 99.9% of the CPU, the idle zone running sendmail will
reject connections because the load average has been exceeded,
even though FSS will guarantee it more CPU.

Jim Mauro wrote:

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.


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.

zones-discuss mailing list

Reply via email to