Print-friendly Version

Zone Resource Control in the Solaris 10 08/07 OS

Victor Feng, May 2008

Starting with the Solaris 10 08/07 Operating System, we can set up resource control for zones directly. For example, we can set up the number of CPUs that a zone can use or a range for the number of CPUs. We can also set up how much memory there is for a zone, including physical, swap, and locked memory. This article provides a few resource control tips that might help.

Although the Solaris 10 08/07 OS allows you to specify how many CPUs can be used in a zone, sometimes this does not work out well. For example, I use dedicated-cpu for three zones in an 8-core Sun Fire T2000 server. Each zone has 4-20 specified for ncpus with a different importance value. However, when the system is fully utilized, the importance value does not always play its role. Sometimes, a zone with a lower importance value consumes a higher percentage of the computing resources than a zone with higher importance.

In the following, I demonstrate that cpu-shares works well.

root@bigfoot# dispadmin -d
FSS     (Fair Share)
root@bigfoot# zonecfg -z global info rctl
rctl:
        name: zone.cpu-shares
        value: (priv=privileged,limit=4,action=none)
root@bigfoot# zonecfg -z bighead info rctl name=zone.cpu-shares
rctl:
        name: zone.cpu-shares
        value: (priv=privileged,limit=3,action=none)
root@bigfoot# zonecfg -z bighand info rctl name=zone.cpu-shares
rctl:
        name: zone.cpu-shares
        value: (priv=privileged,limit=3,action=none)

Generate 20 processes in zone bighead:

<username>@bighead> perl -e 'while (--$ARGV[0] and fork) {}; while () {}'
20 &

Generate 12 processes in zone bighand:

<username>@bighand> perl -e 'while (--$ARGV[0] and fork) {}; while () {}'
12 &

root@bigfoot# vmstat 3 3
 kthr      memory            page            disk          faults
 cpu
 r b w   swap      free  re  mf pi  po fr de sr s1 s2 s3 s4  in   sy
 cs   us  sy id
 4 0 0 37954888 15215072 66 206 259  1  1  0 60 13 -0 -0 24 818 4186
 1780 64  0  36
 0 0 0 38747216 15152224 0    5   0  0  0  0  0  0  0  0  0 768  272
 339 100  0   0
 0 0 0 38746960 15151968 0    0   0  0  0  0  0  0  0  0  0 788  247
 347 100  0   0

root@bigfoot# prstat -Z
ZONEID    NPROC  SWAP   RSS MEMORY      TIME  CPU ZONE
     1       55  202M  264M   1.6%   0:36:11  62% bighead
     2       47  199M  263M   1.6%   0:20:29  37% bighand
     0       49  219M  291M   1.8%   0:01:36 0.1% global

As we see, when the system is not fully utilized, each zone uses as many computing resources as it needs.

Now, we will generate 15 processes in zone bigfoot to see how the bighead and bighand zones consume the computing resources:

root@bigfoot# perl -e 'while (--$ARGV[0] and fork) {}; while () {}'
15 &

root@bigfoot# vmstat 3 3
 kthr      memory            page            disk          faults
 cpu
 r  b w   swap      free   re  mf  pi po fr de sr s1 s2 s3 s4  in   sy
 cs   us   sy id
 5  0 0 37520616 15249888 102 314 406  1  1  0 94 13 -0 -0 24 869 6466
 2592  50  1 49
 15 0 0 38745928 15151392   0   5   0  0  0  0  0  1  0  0  0 806  325
 366  100  0  0
 15 0 0 38745672 15151136   0   0   0  0  0  0  0  0  0  0  0 739  234
 320  100  0  0

root@bigfoot# prstat -Z
ZONEID    NPROC  SWAP   RSS MEMORY      TIME  CPU ZONE
     0       65  228M  298M   1.8%   1:32:55  40% global
     1       55  202M  264M   1.6%   1:59:48  30% bighead
     2       47  199M  263M   1.6%   1:37:32  29% bighand

root@bigfoot# prstat -Z
ZONEID    NPROC  SWAP   RSS MEMORY      TIME  CPU ZONE
     0       65  228M  298M   1.8%   1:19:15  38% global
     2       47  199M  263M   1.6%   1:27:31  31% bighand
     1       55  202M  264M   1.6%   1:48:24  31% bighead

As we see, each zone is consuming a portion of the computing resources according to its cpu-shares value when the system's computing resources are fully utilized.

For zone bighead running Oracle Database 10g Enterprise Edition with total memory of 2 Gbytes (1.5 Gbytes System Global Area [SGA] and 0.5 Gbytes Process Global area [PGA]), we might just give a maximum of 3 Gbytes memory and 1.5 Gbytes swap space, as follows:

zonecfg:bighead> info capped-memory
capped-memory:
        physical: 3G
        [swap: 1.5G]

Start up the Oracle database in zone bighead:

oracle@bighead> sqlplus /nolog
SQL> conn / as sysdba
SQL& startup
ORA-27102: out of memory
SVR4 Error: 12: Not enough space

So the swap here is not physical swap space. Based on Sun documents, swap here means the total amount of swap that can be consumed by user process address space mappings and tmpfs mounts for this zone. When we set up swap, the capped-memory swap should be set proportionately. For example:

<username>@bigfoot> vmstat -p 5
 memory           page          executable      anonymous
 filesystem
 swap     free     re  mf  fr  de  sr  epi  epo  epf  api
 apo  apf fpi fpo fpf
 38671464 15156336 40  77   1   0   5 1442    0    0  242
 0    0    44   1   1
 38875352 15312016  0   3   0   0   0    0    0    0    0
 0    0     0   0   0

In our case, it should be 3 * ( 38 / 15 ), which equals 7 Gbytes.

zonecfg:bighead> info capped-memory
capped-memory:
physical: 1G
[swap: 7G]
[locked: 1G]

The Oracle database took a while to start up. The Resident Set Size (RSS) memory consumed by the zone fluctuated around, as follows:

# prstat -Z
ZONEID NPROC  SWAP   RSS  MEMORY    TIME  CPU  ZONE
36        54  1824M  158M  1.0%  0:01:54 0.5%  bighead
36        54  1824M 1779M 11%    0:01:59 0.3%  bighead
36        55  1828M  258M  1.6%  0:02:01 0.6%  bighead
36        55  1829M 1788M 11%    0:02:13 0.3%  bighead

But 1779 Mbytes is much more than 1 Gbyte. Sun is aware of this known bug.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.