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).
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
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.
--
--------------------------------------------------------------------------
Jeff VICTOR Sun Microsystems jeff.victor @ sun.com
OS Ambassador Sr. Technical Specialist
Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq
--------------------------------------------------------------------------
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
