Resource Controls Concepts
In the Solaris Operating System, the concept of a per-process resource limit has
been extended to the task and project entities described in Chapter 2, Projects and Tasks (Overview). These enhancements
are provided by the resource controls (rctls) facility. In addition, allocations that were set
through the /etc/system tunables are now automatic or configured through the resource controls
mechanism as well.
A resource control is identified by the prefix zone, project, task, or
process. Resource controls can be observed on a system-wide basis. It is possible
to update resource control values on a running system.
For a list of the standard resource controls that are available in
this release, see Available Resource Controls See Resource Type Properties for information on available zone-wide resource controls.
Resource Limits and Resource Controls
UNIX systems have traditionally provided a resource limit facility (rlimit). The rlimit
facility allows administrators to set one or more numerical limits on the amount
of resources a process can consume. These limits include per-process CPU time used,
per-process core file size, and per-process maximum heap size. Heap size is the amount of
scratch memory that is allocated for the process data segment.
The resource controls facility provides compatibility interfaces for the resource limits facility. Existing applications
that use resource limits continue to run unchanged. These applications can be observed
in the same way as applications that are modified to take advantage of
the resource controls facility.
Interprocess Communication and Resource Controls
Processes can communicate with each other by using one of several types of
interprocess communication (IPC). IPC allows information transfer or synchronization to occur between processes. Prior
to the Solaris 10 release, IPC tunable parameters were set by adding an
entry to the /etc/system file. The resource controls facility now provides resource controls
that define the behavior of the kernel's IPC facilities. These resource controls replace the
Obsolete parameters might be included in the /etc/system file on this Solaris system.
If so, the parameters are used to initialize the default resource control values
as in previous Solaris releases. However, using the obsolete parameters is not recommended.
To observe which IPC objects are contributing to a project's usage, use the
ipcs command with the -J option. See How to Use ipcs to view an example display. For
more information about the ipcs command, see ipcs(1).
For information about Solaris system tuning, see the Solaris Tunable Parameters Reference Manual.
Resource Control Constraint Mechanisms
Resource controls provide a mechanism for the constraint of system resources. Processes, tasks,
projects, and zones can be prevented from consuming amounts of specified system resources.
This mechanism leads to a more manageable system by preventing over-consumption of resources.
Constraint mechanisms can be used to support capacity-planning processes. An encountered constraint can
provide information about application resource needs without necessarily denying the resource to the
Project Attribute Mechanisms
Resource controls can also serve as a simple attribute mechanism for resource management
facilities. For example, the number of CPU shares made available to a project
in the fair share scheduler (FSS) scheduling class is defined by the project.cpu-shares
resource control. Because the project is assigned a fixed number of shares by
the control, the various actions associated with exceeding a control are not relevant.
In this context, the current value for the project.cpu-shares control is considered an attribute
on the specified project.
Another type of project attribute is used to regulate the resource consumption of
physical memory by collections of processes attached to a project. These attributes have
the prefix rcap, for example, rcap.max-rss. Like a resource control, this type
of attribute is configured in the project database. However, while resource controls are synchronously
enforced by the kernel, resource caps are asynchronously enforced at the user level
by the resource cap enforcement daemon, rcapd. For information on rcapd, see
Chapter 10, Physical Memory Control Using the Resource Capping Daemon (Overview) and rcapd(1M).
The project.pool attribute is used to specify a pool binding for a project.
For more information on resource pools, see Chapter 12, Resource Pools (Overview).