Brian Kolaci wrote:
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.

Why would you still need sendmail to throttle itself? The two mechanisms (self-throttling and throttling-by-FSS) achieve the same goal. Why use two hammers to pound in one nail?

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.

Jeff VICTOR              Sun Microsystems            jeff.victor @
OS Ambassador            Sr. Technical Specialist
Solaris 10 Zones FAQ:
zones-discuss mailing list

Reply via email to