Editing UBC parameters

All the existing parameters are listed in the below table.

By importance, the parameters are divided into 3 groups: primary parameters,
secondary parameters and auxiliary parameters.
More detailed description of the parameters and the resource control
mechanisms governed by the parameters is provided below.

== Resource control parameters table ==

{| class="wikitable"
! Name !! Description
|-
| colspan="2" align="center" | Primary parameters
|-
| numproc        || Number of processes and threads.
|-
| numtcpsock     || Number of TCP sockets.
|-
| numothersock   || Number of sockets other than TCP.
|-
| vmguarpages    || Memory allocation guarantee, in pages.
|-
| colspan="2" align="center" | Secondary parameters
|-
| kmemsize       || Size of unswappable kernel memory, allocated for processes in this [[VE]].
|-
| tcpsndbuf      || Total size of TCP send buffers.
|-
| tcprcvbuf      || Total size of TCP receive buffers.
|-
| othersockbuf   || Total size of UNIX-domain socket buffers, UDP and other datagram protocol send buffers.
|-
| dgramrcvbuf    || Receive buffers of UDP and other datagram protocols.
|-
| oomguarpages   || The guaranteed amount of memory for the case the memory is “over-booked” (out-of-memory kill guarantee), in pages.
|-
| privvmpages    || Memory allocation limit, in pages.
|-
| colspan="2" align="center" | Auxiliary parameters
|-
| lockedpages    || Process pages not allowed to be swapped out (pages locked by <code>mlock(2)</code>).
|-
| shmpages       || Total size of shared memory (IPC, shared anonymous mappings and <code>tmpfs</code> objects), in pages.
|-
| physpages      || Total number of RAM pages used by processes.
|-
| numfile        || Number of open files.
|-
| numflock       || Number of file locks.
|-
| numpty         || Number of pseudo-terminals.
|-
| numsiginfo     || Number of <code>siginfo</code> structures.
|-
| dcachesize     || Total size of <code>dentry</code> and <code>inode</code> structures locked in memory.
|-
| numiptent      || Number of NETFILTER (IP packet filtering) entries.
|}

== General information about all parameters ==
All resource control parameters have some common properties
and some differences.

<ol>
<li>Most parameters provide both accounting of some system resource
and allow controlling its consumption.
The exceptions are <code>physpages</code> (accounting only)
and <code>vmguarpages</code> (no accounting, control only), explained below.</li>

<li>Each parameter has 2 configuration variables, called <code>barrier</code> and <code>limit</code>.

Although both 2 variables are changeable, only one or none of them may be
effectively used for the resource control for some parameters.
For example, <code>physpages</code> is an accounting-only parameter and both its
configuration variables are not effectively used in the current OpenVZ
version.

The description of each parameter explains the meaning of the <code>barrier</code>
and the <code>limit</code> and what they should be set to if they are not
effectively used.

In general, for all parameters the <code>barrier</code> should not be greater than
the <code>limit</code>.</li>

<li>The parameters control
how the resources are distributed between Virtual Environments in terms of
* limits, i.e.&nbsp;upper boundaries on what this Virtual Environment can consume, and
* guarantees, i.e.&nbsp;mechanisms ensuring that this Virtual Environment
can get the assigned “resources” regardless of the activity and the amount
of resources required by other Virtual Environments.

The parameters containing “<code>guar</code>” in their names,
i.e.&nbsp;<code>vmguarpages</code> and <code>oomguarpages</code> are Virtual Environment's
guarantees.
They guarantee availability of resources and certain service level
up to the value, specified by the <code>barrier</code>,
and do not guarantee above the <code>barrier</code>.
However, these parameters do not impose usage restrictions.
The guarantees are discussed in more detail in the paragraphs describing
these parameters.

The <code>limit</code> of <code>vmguarpages</code> and <code>oomguarpages</code> should be
set to the maximal value (i.e. <code>2147483647</code> on a 32-bit architecture).
</li>

<li>
For some resource limiting parameters, such as <code>kmemsize</code>,
both <code>barrier</code> and <code>limit</code> settings are effectively used.
If the resource usage exceeds the <code>barrier</code> but doesn't exceed the
<code>limit</code>, vital operations (such as process stack expansion)
are still allowed to allocate new
resources, and other ones are not allowed.
A gap between the <code>barrier</code> and the <code>limit</code> gives applications
better chances to handle resource shortage gracefully.

For other resource limiting parameters, such as <code>numproc</code>,
<code>barrier</code> and <code>limit</code> should be set to the same value.
</li>

<li>
Each parameter has “natural units of measurement” — the units
of measurement of values shown via <code>/proc/user_beancounters</code> interface and accepted by [[vzctl]].
Values related to parameters with names starting with <code>num</code> are measured
in pieces.
Values related to parameters with names ending with <code>pages</code> are measured
in memory pages (memory page is equal to 4 kilobytes on IA-32 hardware).
The remaining values (parameters ending with <code>size</code> and <code>buf</code>)
are measured in bytes.
</li>

</ol>