Previous
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 rcapd.
In determining caps on projects, consider these 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 machine 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 With rcapstat and the rcapstat(1) man page for more information. |
Reporting on shared memory | The daemon cannot determine which pages of memory are shared with other processes or which are mapped multiple times within the same process. Since rcapd assumes that each page is unique, this results in a discrepancy between the reported (estimated) RSS and the actual RSS. Certain workloads, such as databases, use shared memory extensively. For these workloads, you can sample a project's regular usage to determine a suitable initial cap value. Use output from the prstat command with the -J option. See the prstat(1M) man page. |
rcapd Operation Intervals
You can tune the intervals for the periodic operations performed by rcapd.
All intervals are specified in seconds. The rcapd operations and their default interval values are described in the following table.
Operation | Default Interval Value in Seconds | Description |
|---|---|---|
scan | 15 | Number of seconds between scans for processes that have joined or left a project workload. Minimum value is 1 second. |
sample | 5 | Number of seconds between samplings of resident set size and subsequent cap enforcements. Minimum value is 1 second. |
report | 5 | Number of seconds between updates to paging statistics. If set to 0, statistics are not updated, and output from rcapstat is not current. |
config | 60 | Number of seconds between reconfigurations. In a reconfiguration event, rcapadm reads the configuration file for updates, and scans the project database for new or revised project caps. Sending a SIGHUP to rcapd causes an immediate reconfiguration. |
To tune intervals, see How to Set Operation Intervals.
Determining rcapd Scan Intervals
The scan interval controls how often rcapd looks for new processes. On systems with many processes running, the scan through the list takes more time, so it might be preferable to lengthen the interval in order to reduce the overall CPU time spent. However, the scan interval also represents the minimum amount of time that a process must exist to be attributed to a capped workload. If there are workloads that run many short-lived processes, rcapd might not attribute the processes to a workload if the scan interval is lengthened.
Determining Sample Intervals
The sample interval configured with rcapadm is the shortest amount of time rcapd waits between sampling a workload's usage and enforcing the cap if it is exceeded. If you reduce this interval, rcapd will, under most conditions, enforce caps more frequently, possibly resulting in increased I/O due to paging. However, a shorter sample interval can also lessen the impact that a sudden increase in a particular workload's physical memory usage might have on other workloads. The window between samplings, in which the workload can consume memory unhindered and possibly take memory from other capped workloads, is narrowed.
If the sample interval specified to rcapstat is shorter than the interval specified to rcapd with rcapadm, the output for some intervals can be zero. This situation occurs because rcapd does not update statistics more frequently than the interval specified with rcapadm. The interval specified with rcapadm is independent of the sampling interval used by rcapstat.
Monitoring Resource Utilization With rcapstat
Use rcapstat to monitor the resource utilization of capped projects. To view an example rcapstat report, see Producing Reports With rcapstat.
You can set the sampling interval for the report and specify the number of times that statistics are repeated.
interval | Specifies the sampling interval in seconds. The default interval is 5 seconds. |
count | Specifies the number of times that the statistics are repeated. By default, rcapstat reports statistics until a termination signal is received or until the rcapd process exits. |
The paging statistics in the first report issued by rcapstat show the activity since the daemon was started. Subsequent reports reflect the activity since the last report was issued.
The following table defines the column headings in an rcapstat report.
rcapstat Column Headings | Description |
|---|---|
id | The project ID of the capped project. |
project | The project name. |
nproc | The number of processes in the project. |
vm | The total amount of virtual memory size used by processes in the project, including all mapped files and devices, in kilobytes (K), megabytes (M), or gigabytes (G). |
rss | The estimated amount of the total resident set size (RSS) of the processes in the project, in kilobytes (K), megabytes (M), or gigabytes (G), not accounting for pages that are shared. |
cap | The RSS cap defined for the project. See Attribute to Limit Physical Memory Usage or the rcapd(1M) man page for information about how to specify memory caps. |
at | The total amount of memory that rcapd attempted to page out since the last rcapstat sample. |
avgat | The average amount of memory that rcapd attempted to page out during each sample cycle that occurred since the last rcapstat sample. The rate at which rcapd samples collection RSS can be set with rcapadm. See rcapd Operation Intervals. |
pg | The total amount of memory that rcapd successfully paged out since the last rcapstat sample. |
avgpg | An estimate of the average amount of memory that rcapd successfully paged out during each sample cycle that occurred since the last rcapstat sample. The rate at which rcapd samples process RSS sizes can be set with rcapadm. See rcapd Operation Intervals. |
Commands Used With rcapd
Command Reference | Description |
|---|---|
rcapstat(1) | Monitors the resource utilization of capped projects. |
rcapadm(1M) | Configures the resource capping daemon, displays the current status of the resource capping daemon if it has been configured, and enables or disables resource capping |
rcapd(1M) | The resource capping daemon. |