Go to main content

Administering Resource Management in Oracle® Solaris 11.4

Exit Print View

Updated: August 2018
 
 

Managing the Resource Capping Daemon

You use the rcapadm command to configure rcapd. You can use the rcapadm command to perform the following resource capping actions:

  • Enable or disable resource capping

  • Display the current status of the configured resource capping daemon

You must be the root user or have the required administrative rights to use rcapadm.

The rcapadm command can set the following parameters:

rcapd mode

Defines whether rcapd must enforce the caps or log the scan results. rcapd can support the following operation modes:

log-only

rcapd prints log messages for every rss sample interval for each collection. No further action is taken.

pageout

The default mode. rcapd prints log messages for rss sample intervals for each collection that exceeds its RSS cap. rcapd then enforces caps on the collection.

rss sample interval

The interval used for sampling resident set size (RSS) for each process collection. For each rss sample interval in seconds, the RSS of each collection is updated. This measurement is used by rcapd to enforce caps on a collection.

Configuration changes can be incorporated into the rcapd daemon on demand by sending a SIGHUP (see the kill(1) man page).

If used without arguments, the rcapadm command displays the current status of the resource capping daemon.

The following subsections discuss cap enforcement and cap values.

Using the Resource Capping Daemon on a System With Zones Installed

You can control resident set size (RSS) usage of a zone by setting the capped-memory resource when you configure the zone. For more information, see Capped Memory and Physical Memory Control in Oracle Solaris Zones Configuration Resources. To use the capped-memory resource, the resource-cap package must be installed in the global zone. You can run the rcapd daemon within a zone, including the global zone, to enforce memory caps on projects in that zone.

You can set a temporary cap for the maximum amount of memory that can be consumed by a specified zone, until the next reboot. See Example: How to Specify a Temporary Resource Cap for a Zone.

If you are using the rcapd daemon on a zone to regulate physical memory consumption by processes running in projects that have resource caps defined, you must configure the daemon in those zones.

When choosing memory caps for applications in different zones, you generally do not have to consider that the applications reside in different zones. The exception is per-zone services. Per-zone services consume memory. This memory consumption must be considered when determining the amount of physical memory for a system, as well as memory caps.

Unenforced Caps and rcapd Daemon Operations

If a process collection is found to exceed its cap for an extended period of time, the rcapd daemon can decide to stop or to resume enforcing caps for that collection. If the daemon stops enforcing caps, a detailed error message is logged reporting the cause and suggesting setting appropriate caps.

If at a later time the daemon determines that the rss of a collection can be reduced to match its cap set, the daemon can resume enforcing the caps.

You can use the following methods to force the rcapd daemon to resume enforcing caps:

  • Set an appropriate cap on the collection. See Determining Cap Values.

  • Examine the process log and restart the rcapd daemon.

Determining Cap Values

If a project cap is set too low, there might not be enough memory for the workload to proceed effectively under normal conditions. The paging that occurs because the workload requires more memory has a negative effect on system performance.

Projects that have caps set too high can consume available physical memory before their caps are exceeded. In this case, physical memory is effectively managed by the kernel and not by the rcapd daemon.

In determining caps on projects, consider the following factors:

Impact on I/O system

The daemon can attempt to reduce a project workload's physical memory usage whenever the sampled usage exceeds the project's cap. During cap enforcement, the swap devices and other devices that contain files that the workload has mapped are used. The performance of the swap devices is a critical factor in determining the performance of a workload that routinely exceeds its cap. The execution of the workload is similar to running it on a system with the same amount of physical memory as the workload's cap.

Impact on CPU usage

The daemon's CPU usage varies with the number of processes in the project workloads it is capping and the sizes of the workloads' address spaces.

A small portion of the daemon's CPU time is spent sampling the usage of each workload. Adding processes to workloads increases the time spent sampling usage.

Another portion of the daemon's CPU time is spent enforcing caps when they are exceeded. The time spent is proportional to the amount of virtual memory involved. CPU time spent increases or decreases in response to corresponding changes in the total size of a workload's address space. This information is reported in the vm column of rcapstat output. See Monitoring Resource Utilization of Capped Projects and the rcapstat(1) man page for more information.

Reporting on shared memory

The rcapd daemon reports the RSS of pages of memory that are shared with other processes or mapped multiple times within the same process as a reasonably accurate estimate. If processes in different projects share the same memory, then that memory is counted towards the RSS total for all projects sharing the memory.

The estimate is usable with workloads such as databases, which utilize shared memory extensively. For database workloads, you can also sample a project's regular usage to determine a suitable initial cap value by using output from the –J or –Z options of the prstat command. For more information, see the prstat(8) man page.