Difference between revisions of "UBC parameters"
m (Refer to MAX_ULONG →General information about all parameters) |
(LONG_MAX) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
All the existing parameters are listed in the [[UBC parameters table]]. | All the existing parameters are listed in the [[UBC parameters table]]. | ||
| − | By importance, the parameters are divided into 3 groups: primary parameters, | + | By importance, the parameters are divided into 3 groups: [[UBC primary parameters|primary parameters]], |
| − | secondary parameters and auxiliary parameters. | + | [[UBC secondary parameters|secondary parameters]] and [[UBC auxiliary parameters|auxiliary parameters]]. |
More detailed description of the parameters and the resource control | More detailed description of the parameters and the resource control | ||
| − | mechanisms governed by the parameters is provided | + | mechanisms governed by the parameters is provided in the appropriate articles. |
== General information about all parameters == | == General information about all parameters == | ||
| Line 34: | Line 34: | ||
<li>The parameters control | <li>The parameters control | ||
| − | how the resources are distributed between | + | how the resources are distributed between containers in terms of |
| − | * limits, i.e. upper boundaries on what this | + | * limits, i.e. upper boundaries on what this container can consume, and |
| − | * guarantees, i.e. mechanisms ensuring that this | + | * guarantees, i.e. mechanisms ensuring that this container can get the assigned “resources” regardless of the activity and the amount of resources required by other containers. |
The parameters containing “<code>guar</code>” in their names, | The parameters containing “<code>guar</code>” in their names, | ||
| − | i.e. <code>vmguarpages</code> and <code>oomguarpages</code> are | + | i.e. <code>vmguarpages</code> and <code>oomguarpages</code> are container's |
guarantees. | guarantees. | ||
They guarantee availability of resources and certain service level | They guarantee availability of resources and certain service level | ||
| Line 49: | Line 49: | ||
The <code>limit</code> of <code>vmguarpages</code> and <code>oomguarpages</code> should be | The <code>limit</code> of <code>vmguarpages</code> and <code>oomguarpages</code> should be | ||
| − | set to the maximal value | + | set to the maximal value [[LONG_MAX]]. |
</li> | </li> | ||
| Line 80: | Line 80: | ||
The properties of parameters are summarized in [[UBC parameter properties]]. | The properties of parameters are summarized in [[UBC parameter properties]]. | ||
| + | |||
| + | {{Note|Continue reading with [[UBC primary parameters]], [[UBC secondary parameters]] and [[UBC auxiliary parameters]].}} | ||
Latest revision as of 13:48, 25 January 2011
|
All the existing parameters are listed in the UBC parameters 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 in the appropriate articles.
General information about all parametersEdit
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
barrierandlimit. 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,physpagesis 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 thebarrierand thelimitand what they should be set to if they are not effectively used. In general, for all parameters thebarriershould not be greater than thelimit. - The parameters control
how the resources are distributed between containers in terms of
- limits, i.e. upper boundaries on what this container can consume, and
- guarantees, i.e. mechanisms ensuring that this container can get the assigned “resources” regardless of the activity and the amount of resources required by other containers.
guar” in their names, i.e.vmguarpagesandoomguarpagesare container'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. Thelimitofvmguarpagesandoomguarpagesshould be set to the maximal value LONG_MAX. -
For some resource limiting parameters, such as
kmemsize, bothbarrierandlimitsettings are effectively used. If the resource usage exceeds thebarrierbut 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 thebarrierand thelimitgives applications better chances to handle resource shortage gracefully. For other resource limiting parameters, such asnumproc,barrierandlimitshould be set to the same value. -
Each parameter has “natural units of measurement” — the units
of measurement of values shown via
/proc/user_beancountersinterface and accepted by vzctl. Values related to parameters with names starting withnumare measured in pieces. Values related to parameters with names ending withpagesare measured in memory pages (memory page is equal to 4 kilobytes on IA-32 hardware). The remaining values (parameters ending withsizeandbuf) are measured in bytes. See more at UBC parameter units.
The properties of parameters are summarized in UBC parameter properties.
| Note: Continue reading with UBC primary parameters, UBC secondary parameters and UBC auxiliary parameters. |