The following example uses project user1, which has an RSS in excess of its RSS cap.
The following command produces five reports at 5-second sampling intervals.
user1machine% rcapstat 5 5
id project nproc vm rss cap at avgat pg avgpg 376565 user1 3 6249M 6144M 6144M 690M 220M 5528K 2764K 376565 user1 3 6249M 6144M 6144M 0M 131M 4912K 1637K 376565 user1 3 6249M 6171M 6144M 27M 147M 6048K 2016K 376565 user1 3 6249M 6146M 6144M 4872M 174M 4368K 1456K 376565 user1 3 6249M 6156M 6144M 12M 161M 3376K 1125K
The user1 project has three processes that are actively using physical memory. The positive values in the pg column indicate that rcapd is consistently paging out memory as it attempts to meet the cap by lowering the physical memory utilization of the project's processes. However, rcapd does not succeed in keeping the RSS below the cap value. This is indicated by the varying rss values that do not show a corresponding decrease. As soon as memory is paged out, the workload uses it again and the RSS count goes back up. This means that all of the project's resident memory is being actively used and the working set size (WSS) is greater than the cap. Thus, rcapd is forced to page out some of the working set to meet the cap. Under this condition, the system will continue to experience high page fault rates, and associated I/O, until one of the following occurs:
The WSS becomes smaller.
The cap is raised.
The application changes its memory access pattern.
In this situation, shortening the sample interval might reduce the discrepancy between the RSS value and the cap value by causing rcapd to sample the workload and enforce caps more frequently.