Difference between revisions of "UBC parameters"
(created (not finished yet)) |
(more contents added) |
||
Line 1: | Line 1: | ||
+ | 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" | {| class="wikitable" | ||
! Name !! Description | ! Name !! Description | ||
Line 48: | Line 57: | ||
| numiptent || Number of NETFILTER (IP packet filtering) entries. | | 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. upper boundaries on what this Virtual Environment | ||
+ | can consume, and | ||
+ | * guarantees, i.e. 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. <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 ($2147483647$ 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> | ||
+ | |||
+ | </ul> |
Revision as of 03:32, 22 August 2006
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
Name | Description |
---|---|
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. |
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. |
Auxiliary parameters | |
lockedpages | Process pages not allowed to be swapped out (pages locked by mlock(2) ).
|
shmpages | Total size of shared memory (IPC, shared anonymous mappings and tmpfs 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 siginfo structures.
|
dcachesize | Total size of dentry and inode 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.
- Most parameters provide both accounting of some system resource
and allow controlling its consumption.
The exceptions are
physpages
(accounting only) andvmguarpages
(no accounting, control only), explained below. - Each parameter has 2 configuration variables, called
barrier
andlimit
. 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,physpages
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 thebarrier
and thelimit
and what they should be set to if they are not effectively used. In general, for all parameters thebarrier
should not be greater than thelimit
. - The parameters control
how the resources are distributed between Virtual Environments in terms of
- limits, i.e. upper boundaries on what this Virtual Environment
- guarantees, i.e. mechanisms ensuring that this Virtual Environment
guar
” in their names, i.e.vmguarpages
andoomguarpages
are Virtual Environment's guarantees. They guarantee availability of resources and certain service level up to the value, specified by thebarrier
, and do not guarantee above thebarrier
. However, these parameters do not impose usage restrictions. The guarantees are discussed in more detail in the paragraphs describing these parameters. Thelimit
ofvmguarpages
andoomguarpages
should be set to the maximal value ($2147483647$ on a 32-bit architecture). -
For some resource limiting parameters, such as
kmemsize
, bothbarrier
andlimit
settings are effectively used. If the resource usage exceeds thebarrier
but doesn't exceed thelimit
, vital operations (such as process stack expansion) are still allowed to allocate new resources, and other ones are not allowed. A gap between thebarrier
and thelimit
gives applications better chances to handle resource shortage gracefully. For other resource limiting parameters, such asnumproc
,barrier
andlimit
should be set to the same value. -
Each parameter has “natural units of measurement” — the units
of measurement of values shown via
/proc/user_beancounters
interface and accepted by vzctl. Values related to parameters with names starting withnum
are measured in pieces. Values related to parameters with names ending withpages
are measured in memory pages (memory page is equal to 4 kilobytes on IA-32 hardware). The remaining values (parameters ending withsize
andbuf
) are measured in bytes.