JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones
search filter icon
search icon

Document Information


Part I Resource Management

1.  Introduction to Solaris 10 Resource Management

2.  Projects and Tasks (Overview)

3.  Administering Projects and Tasks

4.  Extended Accounting (Overview)

5.  Administering Extended Accounting (Tasks)

6.  Resource Controls (Overview)

7.  Administering Resource Controls (Tasks)

8.  Fair Share Scheduler (Overview)

9.  Administering the Fair Share Scheduler (Tasks)

10.  Physical Memory Control Using the Resource Capping Daemon (Overview)

11.  Administering the Resource Capping Daemon (Tasks)

12.  Resource Pools (Overview)

What's New in Resource Pools and Dynamic Resource Pools?

Introduction to Resource Pools

Introduction to Dynamic Resource Pools

About Enabling and Disabling Resource Pools and Dynamic Resource Pools

Resource Pools Used in Zones

When to Use Pools

Resource Pools Framework

/etc/pooladm.conf Contents

Pools Properties

Implementing Pools on a System

project.pool Attribute

SPARC: Dynamic Reconfiguration Operations and Resource Pools

Creating Pools Configurations

Directly Manipulating the Dynamic Configuration

poold Overview

Managing Dynamic Resource Pools

Configuration Constraints and Objectives

Configuration Constraints

pset.min Property and pset.max Property Constraints

cpu.pinned Property Constraint

pool.importance Property Constraint

Configuration Objectives

wt-load Objective

The locality Objective

utilization Objective

Configuration Objectives Example

poold Properties

poold Features That Can Be Configured

poold Monitoring Interval

poold Logging Information

Configuration Information Logging

Monitoring Information Logging

Optimization Information Logging

Logging Location

Log Management With logadm

How Dynamic Resource Allocation Works

About Available Resources

Determining Available Resources

Identifying a Resource Shortage

Determining Resource Utilization

Identifying Control Violations

Determining Appropriate Remedial Action

Using poolstat to Monitor the Pools Facility and Resource Utilization

poolstat Output

Tuning poolstat Operation Intervals

Commands Used With the Resource Pools Facility

13.  Creating and Administering Resource Pools (Tasks)

14.  Resource Management Configuration Example

15.  Resource Control Functionality in the Solaris Management Console

Part II Zones

16.  Introduction to Solaris Zones

17.  Non-Global Zone Configuration (Overview)

18.  Planning and Configuring Non-Global Zones (Tasks)

19.  About Installing, Halting, Cloning, and Uninstalling Non-Global Zones (Overview)

20.  Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks)

21.  Non-Global Zone Login (Overview)

22.  Logging In to Non-Global Zones (Tasks)

23.  Moving and Migrating Non-Global Zones (Tasks)

24.  Solaris 10 9/10: Migrating a Physical Solaris System Into a Zone (Tasks)

25.  About Packages and Patches on a Solaris System With Zones Installed (Overview)

26.  Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Tasks)

27.  Solaris Zones Administration (Overview)

28.  Solaris Zones Administration (Tasks)

29.  Upgrading a Solaris 10 System That Has Installed Non-Global Zones

30.  Troubleshooting Miscellaneous Solaris Zones Problems

Part III lx Branded Zones

31.  About Branded Zones and the Linux Branded Zone

32.  Planning the lx Branded Zone Configuration (Overview)

33.  Configuring the lx Branded Zone (Tasks)

34.  About Installing, Booting, Halting, Cloning, and Uninstalling lx Branded Zones (Overview)

35.  Installing, Booting, Halting, Uninstalling and Cloning lx Branded Zones (Tasks)

36.  Logging In to lx Branded Zones (Tasks)

37.  Moving and Migrating lx Branded Zones (Tasks)

38.  Administering and Running Applications in lx Branded Zones (Tasks)



How Dynamic Resource Allocation Works

This section explains the process and the factors that poold uses to dynamically allocate resources.

About Available Resources

Available resources are considered to be all of the resources that are available for use within the scope of the poold process. The scope of control is at most a single Solaris instance.

On a system that has zones enabled, the scope of an executing instance of poold is limited to the global zone.

Determining Available Resources

Resource pools encompass all of the system resources that are available for consumption by applications.

For a single executing Solaris instance, a resource of a single type, such as a CPU, must be allocated to a single partition. There can be one or more partitions for each type of resource. Each partition contains a unique set of resources.

For example, a machine with four CPUs and two processor sets can have the following setup:

pset 0: 0 1

pset 1: 2 3

where 0, 1, 2 and 3 after the colon represent CPU IDs. Note that the two processor sets account for all four CPUs.

The same machine cannot have the following setup:

pset 0: 0 1

pset 1: 1 2 3

It cannot have this setup because CPU 1 can appear in only one pset at a time.

Resources cannot be accessed from any partition other than the partition to which they belong.

To discover the available resources, poold interrogates the active pools configuration to find partitions. All resources within all partitions are summed to determine the total amount of available resources for each type of resource that is controlled.

This quantity of resources is the basic figure that poold uses in its operations. However, there are constraints upon this figure that limit the flexibility that poold has to make allocations. For information about available constraints, see Configuration Constraints.

Identifying a Resource Shortage

The control scope for poold is defined as the set of available resources for which poold has primary responsibility for effective partitioning and management. However, other mechanisms that are allowed to manipulate resources within this control scope can still affect a configuration. If a partition should move out of control while poold is active, poold tries to restore control through the judicious manipulation of available resources. If poold cannot locate additional resources within its scope, then the daemon logs information about the resource shortage.

Determining Resource Utilization

poold typically spends the greatest amount of time observing the usage of the resources within its scope of control. This monitoring is performed to verify that workload-dependent objectives are being met.

For example, for processor sets, all measurements are made across all of the processors in a set. The resource utilization shows the proportion of time that the resource is in use over the sample interval. Resource utilization is displayed as a percentage from 0 to 100.

Identifying Control Violations

The directives described in Configuration Constraints and Objectives are used to detect the approaching failure of a system to meet its objectives. These objectives are directly related to workload.

A partition that is not meeting user-configured objectives is a control violation. The two types of control violations are synchronous and asynchronous.

The following events cause asynchronous objective violations:

The contributions of objectives that are not related to workload are assumed to remain constant between evaluations of the objective function. Objectives that are not related to workload are only reassessed when a reevaluation is triggered through one of the asynchronous violations.

Determining Appropriate Remedial Action

When the resource controller determines that a resource consumer is short of resources, the initial response is that increasing the resources will improve performance.

Alternative configurations that meet the objectives specified in the configuration for the scope of control are examined and evaluated.

This process is refined over time as the results of shifting resources are monitored and each resource partition is evaluated for responsiveness. The decision history is consulted to eliminate reconfigurations that did not show improvements in attaining the objective function in the past. Other information, such as process names and quantities, are used to further evaluate the relevance of the historical data.

If the daemon cannot take corrective action, the condition is logged. For more information, see poold Logging Information.