Information Technology Reference
In-Depth Information
This resource constraint can also be dynamically changed for a running zone:
GZ#
prctl -n zone.cpu-shares -r -v 200 -i zone web
Whenever share assignments are changed or Containers using FSS are added
or removed, the proportion of CPU time allowed for each Container changes to
reflect the new total number of shares.
A final note on efficiency and FSS: Although this method does not leave idle
CPU cycles when a workload might use them, the presence of a large number of
Containers on a busy system will tax the scheduler. Its algorithm will use a mea-
surable amount of CPU cycles. On medium and large systems, dozens of running
Containers would be needed for the effect to be noticeable.
Dynamic Resource Pools
Use of the Fair Share Scheduler assumes that multiple
Containers should share the system's processors, or a specific set of those
processors. An alternative—Solaris Dynamic Resource Pools—ensures that a
workload has exclusive access to a set of CPUs. When this feature is used, typically
a Container is configured to have its own pool of CPUs reserved for its exclusive
use. Processes in the global zone and in other Containers never run on that set of
CPUs. This type of resource pool is called a
temporary
pool, because it exists only
when the Container is running. It is also sometimes called a
private
pool because
those CPUs are dedicated (private) to that one Container and its processes.
A resource pool can be of fixed size, or it can be configured to vary in size within
a range that you choose. In the latter situation, the OS will shift CPUs between
pools as their needs change, as shown in Figure 6.5. Each CPU is assigned to ei-
ther a (nondefault) resource pool or the default pool. CPUs in the default pool are
used by global zone processes and processes in Containers that are not configured
to use a pool.
A private pool is not created until its Container boots. If sufficient CPUs are not
available to fulfill the configuration, the Container will not boot, and a diagnostic
message will be displayed. In that case, one of the following steps can be taken to
enable the Container to boot:
Reconfigure the Container with fewer CPUs
■
Reconfigure the Container to share CPUs with other Containers
■
Shift CPUs out of the private pools of other Containers into the default pool
■
Move the Container to a system with sufficient CPUs.
■
For example, consider Figure 6.5, which shows a 32-CPU system with a default
pool of 4-32 CPUs and with Containers Web, App, and DB, which are configured
with pools of 2-6 CPUs, 8-16 CPUs, and 8-12 CPUs, respectively. Solaris will
attempt to assign each pool its maximum quantity of CPUs while leaving the
Search WWH ::
Custom Search