Sun Microsystems 10 manual Fair share scheduler FSS, Fair share scheduler in a zone

Version 3.1-enSolaris 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-sharesmust 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-capsalso 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-lwpswhich 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