Version 3.1-en Solaris 10 Container Guide - 3.1 4. Best Practices Effective: 30/11/2009
4.6.3. Limiting memory resources
[ug] Memory usage by zones is calculated almost exactly (since Solaris 10 8/07). This is done in the
following way: First, the set of all memory segments o f the processes in the zone is determined.
Shared segments appear only once in this set. Next, the memory usage of the segments is added up.
This calculation shows the memory requirements of the zone almost precisely. The memory usage of
the zone can be displayed with prstat -Z, with SWAP indicating the virtual memory used and
RSS the physical memory used. This calculation also works for projects (for example in zones) with
prstat -J . As soon as a limit has been configured, the status of the zones can be displayed with
rcapstat.
The inaccuracy of the calculation above is found in the fact that for example the segment of the
/usr/lib/libc.so library is used by the global zone a nd by all zones that inherit the /usr/lib tree . It is fully
counted for each participating zone but in reality exists only once. So, the zone needs this space but
shares it with others and should therefore only have a portion of it counted. This only pertains to
shared libraries and program code. Essential memory segments are the data sect ors of running
programs and shared segments (e.g. of databases) that do not go beyond the scope of a zone.
(Cookbook: 5.5.11 Implementing memory resource management for zones )
4.6.3.1. Assessing memory requirements for global and l ocal zones
[ug] The global zone meets the following framework conditions of a Solaris operating system:
•Solaris requires approx. 512 MB - 1 GB main memory, depending on the services activated
•Furthermore, 1/32 of the real main memory is kept free for the free list (minfree setting); the
space also serves as disk cache.
•If much traditional I/O takes place with large files (read() and write() instead of mmap()),
12% (approx. 1/8) of the main memory is still required for the corresponding buffer
(segmap setting).
The global zone without applications of a 32 GB system therefore requires about 2 GB; with lots of
traditional I/O the global zone needs 6 GB of memory.
The usage of a local zone can be verified with prstat -Z. Without applications, it amounts to
about 5 - 10 MB, depending on the services installed.
4.6.3.2. Limiting virtual memory
[ug] (From S10 8/07) The entire virtual memory is managed by the kernel. The amount of virtual
memory the processes of a zone are able to use can be limited. This is done by setting the swap
value is set to a certain quantity in the zone configuration using zonecfg: add capped-
memory. This setting cannot be changed by the zone administrator.
As soon as this amount of memory is being used in the zone, applications in the zone are not able to
to request any new memory anymore. The amount of virtual memory is thus hard-limited (capped).
This is the setting by which the amount of memory a zone uses can be limited. This configuration
should be used first before thinking of a physical memory limit.
4.6.3.3. Limiting a zone's physical memory requirement
[ug] The physical memory used by all zone processes can be limited by setting the value physical
in the zone configuration to a certain quantity with zonecfg: add capped-memory. This
setting can not be changed in the zone by the administrator (since S10 8/07).
The behavior of processes in the zone first remains the same. If a virtual memory page has not been
used for a long time, it is swapped to the swap-space (disk). If a swapped memory page is used, it is
swapped in through Solaris' paging mechanism and uses a physical memory page. When a zone with
physical memory limitation boots up, the resource capping daemon (rcapd) is automatically
configured and started in the global zone.
As soon as the rcapd determines that a zone uses more than the configured quantity of physical
main memory, it will actively swap main memory pages of the zone until the limit is observed; the
zone's activity is obstructed and the zone's performance deteriorates. This setting allows the user to
limit the effect on other zones if there is an overall misconfiguration (e.g. database set too big). To
limit the size of a zone, the virtual memory setting should be used.
60