Filter
Top Products
Version 3.1-en Solaris 10 Container Guide - 3.1 4. Best Practices Effective: 30/11/2009
4.6.2.3. Fair share scheduler (FSS)
[ug] When multiple zones are running in one resource pool, then the distribution of CPU time among
these zones is configurable. This configuration is active, when the workload of the processor set
approaches 100% (full load). The process priorities will then be modified by the FSS to achieve the
configured CPU share. However, so long as the utilization of the CPU workload stays below 100%,
the FSS does not intervene.
• For configuration, the fair share scheduler must be activated in the resource pool.
• The value of zone.cpu-shares must be set in the zone by zonecfg: add rctl.
• From Solaris 10 8/07, the number of shares can be adjusted more easily with zonecfg:
set cpu-shares=<number>.
• During full load (100% CPU workload in the resource pool), all the share values of the active
zones are added up and the priorities of processes in these zones are modified such that the
share in CPU power corresponds to the ratio zone.cpu-shares/<sum-of-shares>.
• The fair share scheduler can also be used in-between projects and mixed between zones and
projects in a resource pool.
Comments:
• The project cpu-caps also allows to firmly assign the processors of a resource pool under
partial load
• Since the fair share scheduler can change the runtime behavior of the operating system, it is
recommended to always, if possible, set up a separate resource pool with processor set where
the FSS is to be used.
4.6.2.4. Fair share scheduler in a zone
[ug] If two or more applications within a zone are to receive differing amounts of CPU capacity, the
FSS can also be used in the zone. It is not possible to configure Processor sets within a zone since
the zones' access to processors is restricted.
• The administrator of a zone can configure the resource pools
(pooladm, poolcfg, poolstat).
• Projects can be configured in the zone
(projects, projadd, projmod, projdel, ...)
• The fair share scheduler must be activated in the resource pool of the global zone.
4.6.2.5. Dynamic resource pools
[ug] From Solaris 10 8/07 on, the creation of processor sets has been simplified for the following
standard case: Resource pool with one processor set for one zone. Configuration takes place in the
zonecfg command with add dedicated-cpu.
• During the start of the zone, the system generates a temporary resource pool with processor set
that corresponds to the configuration, and binds the zone to this resource pool.
• The parameters can be changed dynamically just like for general resource pools.
• When the zone is stopped, the resource pool is deleted and the CPUs are released again.
• Since this setting occurs in the zone configuration, it is taken along automatically when a zone
gets moved to a different system. For general resource pools, this configuration must be
transferred manually.
• Dynamic resource pools are especially suitable on systems with many CPUs (large computers,
CMT systems).
(Cookbook: 5.5.9 Dynamic resource pools )
4.6.2.6. Lightweight processes (LWP)
[ug] The limiting of lightweight processes is important for zones. Without such a limit, a denial-of-
service attack on the system from one zone can occur. A lightweight process is required to allow a
thread to run. If a process runs amok within a zone (e.g. a self-starting script that continues to
generate new processes over and over), then the maximum number of LWP's could be reached on
the system and/or the system could run slowly.
• In the zone configuration, the value of zone.max-lwps which limits the number of
lightweight processes can be set with zonecfg: add rctl.
• From Solaris 10 8/07, the number of LWP's can be set more simply by
zonecfg: set max-lwps=<number>.
59