Filter
Top Products
Version 3.1-en Solaris 10 Container Guide - 3.1 4. Best Practices Effective: 30/11/2009
4.6. Resource management
4.6.1. Types of resource management
[dd] There are 3 different types of resource management in all:
• Fair resources: Here, all resources are distributed fairly among all requesters and according to
the defined rules. Example: Fair share scheduler for CPU resources
• Capped resources: Resources can be seen by all requesters. As the upper limit of a resource is
the capping value specified. Unused resources can also be used by others. Example: CPU
capping
• Exclusive resources: Resources are assigned exclusively to the requester and can be used by
him only. Unused resource shares are not available to others. Example: resource pools with
processor sets
4.6.2. CPU resources
[ug] CPU resources can be limited on several different levels in Solaris 10:
• Capping of CPU time for a zone
• Resource pools with processor set (global zone only)
• Fair share scheduler between zones in a resource pool (global zone only)
• Fair share scheduler between projects in a zone
4.6.2.1. Capping of CPU time for a zone
[dd] For this purpose, a CPU capping value is assigned to a zone in the zone configuration. Parts of a
CPU can be specified here, e.g. 0.5 CPUs or 1.57 CPUs. The usable CPU time of a zone is capped
at this contingent. This allows finely granulated CPU assignment on a number of zones even if less
than a whole CPU is to be assigned to a zone. In addition, the zone will not use more CPU resources,
although more CPU time would be available (e.g. at times when the total system is underutilized).
CPU caps must be used where finely granulated CPU rations are required and an upper limit must be
observed. The setting using CPU caps is exact to 1/100 CPUs.
(Cookbook: 5.5.2 Limiting the CPU usage of a zone (CPU capping) )
4.6.2.2. General resource pools
[ug] Resource pools are defined in the global zone to which a processor set can be assigned (see
commands poolcfg and pooladm).
• A processor set contains an upper and a lower limit for the number of processors. This can be
used for dynamic allocation of processors using poold.
• These definitions are static and withstand rebooting.
• A dynamic change is also possible with the prctl command.
• A zone (or a project) can be assigned to such a resource pool. This is done with zonecfg:
set pool=<name> or dynamically with poolbind. All processes of the zone (or of the
project) then run in this resource pool and thus on the CPUs of the processor set defined for the
resource pool.
• If no processor set is assigned, the processes in the resource pool run on the general processor
set (pset_default) which contains all processors by default and where the system
activities take place as well.
Resource pools make sense, if more than one zone (if necessary with FSS) are to run in one
resource pool (and on one processor set).
Resource pools are also appropriate, if individual projects from the global zone are to run in a
resource pool in addition to the local zones. It is, however, recommended not to run any applications
in the global zone due to higher complexity.
58