Resource Controls Concepts

In the Oracle 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.

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. The
resource controls facility provides resource controls that define the behavior of the kernel's
IPC facilities. These resource controls replace the /etc/system tunables.

Obsolete parameters that are used to initialize the default resource control values might
be included in the /etc/system file on this Oracle Solaris system. 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).

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
application.

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).