Difference between revisions of "UBC auxiliary parameters"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(added numpty, numsiginfo, dcachesize, numiptent)
m (Reverted edits by 109.228.171.118 (talk) to last revision by Kir)
 
(16 intermediate revisions by 7 users not shown)
Line 19: Line 19:
  
 
Another example. Each object such as opened file or established network
 
Another example. Each object such as opened file or established network
connection consume certain resources. When the Virtual Environment
+
connection consume certain resources. When the container
 
is close to exhaustion of the resources allowed to him, it is
 
is close to exhaustion of the resources allowed to him, it is
 
usually better to refuse creation of new object than to allow it but deny
 
usually better to refuse creation of new object than to allow it but deny
Line 28: Line 28:
 
<li>
 
<li>
 
These parameters improve fault isolation between applications in the
 
These parameters improve fault isolation between applications in the
same Virtual Environment. Failures or misbehavior of one application
+
same container. Failures or misbehavior of one application
inside a Virtual Environment is more likely to cause hitting a
+
inside a container is more likely to cause hitting a
 
limit on some auxiliary parameter and normal termination of this mis-
 
limit on some auxiliary parameter and normal termination of this mis-
 
behaving application, rather than abnormal termination of some other
 
behaving application, rather than abnormal termination of some other
long-running application inside the same Virtual Environment.
+
long-running application inside the same container.
 
</li>
 
</li>
  
 
<li>
 
<li>
 
These parameters may be used to impose some administrative limits
 
These parameters may be used to impose some administrative limits
on the Virtual Environment (for example, to not allow the user to run
+
on the container (for example, to not allow the user to run
 
database servers by limiting the amount of [[shmpages]], or limiting the
 
database servers by limiting the amount of [[shmpages]], or limiting the
 
number of simultaneous shell sessions through [[numpty]]).
 
number of simultaneous shell sessions through [[numpty]]).
Line 64: Line 64:
  
 
The configuration of this parameter doesn't affect security and
 
The configuration of this parameter doesn't affect security and
stability of the whole system or isolation between Virtual Environments.
+
stability of the whole system or isolation between containers.
 
Its configuration affects functionality and resource shortage reaction
 
Its configuration affects functionality and resource shortage reaction
of applications in the given Virtual Environment only.
+
of applications in the given container only.
  
 
== shmpages ==
 
== shmpages ==
Line 76: Line 76:
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
The configuration of this parameter doesn't affect security and
 
The configuration of this parameter doesn't affect security and
stability of the whole system or isolation between Virtual Environments.
+
stability of the whole system or isolation between containers.
 
Its configuration affects functionality and resource shortage reaction
 
Its configuration affects functionality and resource shortage reaction
of applications in the given Virtual Environment only.
+
of applications in the given container only.
  
 
== physpages ==
 
== physpages ==
Total number of RAM pages used by processes in this Virtual Environment.
+
Total number of RAM pages used by processes in a container.
  
For memory pages used by several different Virtual Environments (mappings of
+
For memory pages used by several different containers (mappings of
 
shared libraries, for example), only a fraction of a page is charged to each
 
shared libraries, for example), only a fraction of a page is charged to each
Virtual Environment.
+
container.
The sum of the <code>physpages</code> usage for all Virtual Environments
+
The sum of the <code>physpages</code> usage for all containers
 
corresponds to the total number of pages used in the system by all
 
corresponds to the total number of pages used in the system by all
Virtual Environments.
+
containers.
  
<code>Physpages</code> is an accounting-only parameter currently.
+
For [[VSwap]]-enabled kernels, the <code>barrier</code> should be set to 0,
In future OpenVZ releases, this parameter will allow to provide guaranteed
+
and the <code>limit</code> limits the total size of RAM used by a container.
amount of application memory, residing in RAM and not swappable.
+
 
For compatibility with future versions, the <code>barrier</code> of this
+
For older kernels, <code>physpages</code> is an accounting-only parameter.
parameter should be set to <code>0</code> and the <code>limit</code> to
+
The <code>barrier</code> should be set to <code>0</code> and the
the maximal allowed value ([[MAX_ULONG]]).
+
<code>limit</code> to 'unlimited' ([[LONG_MAX]]).
  
 
== numfile ==
 
== numfile ==
Line 102: Line 102:
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
The configuration of this parameter doesn't affect security and
 
The configuration of this parameter doesn't affect security and
stability of the whole system or isolation between Virtual Environments.
+
stability of the whole system or isolation between containers.
 
Its configuration affects functionality and resource shortage reaction
 
Its configuration affects functionality and resource shortage reaction
of applications in the given Virtual Environment only.
+
of applications in the given container only.
 +
 
 +
Note: actually currently adjusting the <code>barrier</code> will change the kernel behaviour on "pre-charging" the numfile resource. If you change one you will most likely not notice any changes in container behaviour at all. This ability was added for researching purposes purely.
  
 
== numflock ==
 
== numflock ==
Line 126: Line 128:
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
The configuration of this parameter doesn't affect security and
 
The configuration of this parameter doesn't affect security and
stability of the whole system or isolation between Virtual Environments.
+
stability of the whole system or isolation between containers.
 
Its configuration affects functionality and resource shortage reaction
 
Its configuration affects functionality and resource shortage reaction
of applications in the given Virtual Environment only.
+
of applications in the given container only.
 
However, in OpenVZ systems, the actual number of pseudo-terminals allowed
 
However, in OpenVZ systems, the actual number of pseudo-terminals allowed
for one Virtual Environment is limited to <code>256</code>.
+
for one container is limited to <code>256</code>.
  
 
== numsiginfo ==
 
== numsiginfo ==
Line 139: Line 141:
 
to <code>1024</code> for the whole system.
 
to <code>1024</code> for the whole system.
 
In OpenVZ installations, <code>numsiginfo</code> limit applies to each
 
In OpenVZ installations, <code>numsiginfo</code> limit applies to each
Virtual Environment individually.
+
container individually.
  
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
Very high settings of the <code>limit</code> of this parameter may reduce
 
Very high settings of the <code>limit</code> of this parameter may reduce
 
responsiveness of the system.
 
responsiveness of the system.
It is unlikely that any Virtual Environment will need the limit greater than
+
It is unlikely that any container will need the limit greater than
 
the Linux default — <code>1024</code>.
 
the Linux default — <code>1024</code>.
  
Line 164: Line 166:
 
[[UBC configuration examples]].
 
[[UBC configuration examples]].
 
The configuration of this parameter doesn't affect security and
 
The configuration of this parameter doesn't affect security and
stability of the whole system or isolation between Virtual Environments.
+
stability of the whole system or isolation between containers.
 
Its configuration affects functionality and resource shortage reaction
 
Its configuration affects functionality and resource shortage reaction
of applications in the given Virtual Environment only.
+
of applications in the given container only.
  
 
== numiptent ==
 
== numiptent ==
Line 177: Line 179:
 
Violation of this restriction may cause failures of operations with
 
Violation of this restriction may cause failures of operations with
 
IP packet filter tables (execution of <code>iptables(8)</code>)
 
IP packet filter tables (execution of <code>iptables(8)</code>)
in any Virtual Environment or the host system,
+
in any container or the host system,
or failures of Virtual Environment starts.
+
or failures of container starts.
 +
 
 
Also, large <code>numiptent</code> cause considerable slowdown of processing
 
Also, large <code>numiptent</code> cause considerable slowdown of processing
of network packets.  It is not recommended to allow Virtual Environments
+
of network packets.  It is not recommended to allow containers
 
to create more than 200–300 <code>numiptent</code>.
 
to create more than 200–300 <code>numiptent</code>.
 +
 +
== swappages ==
 +
 +
The amount of swap space to show in container.
 +
 +
{{Note|this parameter is only available in RHEL5-based kernel since version 028stab060.2, in 2.6.27 since kiprensky.}}
 +
 +
The configuration of this parameter doesn't affect security and
 +
stability of the whole system or isolation between containers.
 +
Its configuration only affects the way OpenVZ kernel reports about
 +
available swap in a container. This is needed for some applications
 +
which refuse to run inside a container unless the kernel
 +
report that no less than some specific amount of swap is available.
 +
 +
If <code>limit</code> is set, its value is reported as the amount
 +
of total swap space in a container.
 +
 +
If the <code>limit</code> is set to [[LONG_MAX]] (which is the
 +
in-kernel default for this parameter), all the swap space values
 +
parameters (total, used, free) are reported as 0.
 +
 +
The value of <code>barrier</code> for this beancounter is ignored.
 +
 +
The value of <code>held</code> shows how much swap space
 +
is currently being used for this container.

Latest revision as of 05:45, 21 October 2011

User Beancounters
Definition
/proc/user_beancounters
/proc/bc/
General information
Units of measurement
VSwap
Parameters description
Primary parameters
numproc, numtcpsock, numothersock, vmguarpages
Secondary parameters
kmemsize, tcpsndbuf, tcprcvbuf, othersockbuf, dgramrcvbuf, oomguarpages, privvmpages
Auxiliary parameters
lockedpages, shmpages, physpages, numfile, numflock, numpty, numsiginfo, dcachesize, numiptent, swappages
Internals
User pages accounting
RSS fractions accounting
On-demand accounting
UBC consistency
Consistency formulae
System-wide configuration
vzubc(8)
Configuration examples
Basic
Derived
Intermediate configurations
Tables
List of parameters
Parameter properties
Consistency
Config examples

Configuration of primary and secondary resource control parameters is important for security and stability of the whole system. Auxiliary parameters differ much from primary and secondary parameters in this respect.

The primary functions of auxiliary parameters are the following.

  • These parameters improve application's handling of errors and resource consumption limitations. Without these auxiliary parameters, possible bugs in applications (such as forgetting to unlock locked files or forgetting to collect signals) will cause slowdown and, after some time, killing of the applications because of memory exhaustion. In presence of these parameters, applications will notice the problem (because, for example, attempts to create new file locks start to fail) and show an appropriate message helping to debug the problem. Another example. Each object such as opened file or established network connection consume certain resources. When the container is close to exhaustion of the resources allowed to him, it is usually better to refuse creation of new object than to allow it but deny memory allocation or terminate (in case of complete exhaustion of the resources) an already running application.
  • These parameters improve fault isolation between applications in the same container. Failures or misbehavior of one application inside a container is more likely to cause hitting a limit on some auxiliary parameter and normal termination of this mis- behaving application, rather than abnormal termination of some other long-running application inside the same container.
  • These parameters may be used to impose some administrative limits on the container (for example, to not allow the user to run database servers by limiting the amount of shmpages, or limiting the number of simultaneous shell sessions through numpty).

So, auxiliary parameters play a role similar to limits imposed by setrlimit(2) interface and limits configurable by sysctl(8) in standard Linux installations.

Because of this helper role in resource control, system management software may show auxiliary parameters only in advanced mode for experienced administrators and hide them in “basic” management modes.

lockedpages[edit]

Process pages not allowed to be swapped out (pages locked by mlock(2)).

The size of these pages is also accounted into kmemsize. The barrier may be set equal to the limit or may allow some gap between the barrier and the limit, depending on the nature of applications using memory locking features.

Note that typical server applications like Web, FTP, mail servers do not use memory locking features.

The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only.

shmpages[edit]

The total size of shared memory (IPC, shared anonymous mappings and tmpfs objects).

These pages are also accounted into privvmpages.

The barrier should be set equal to the limit. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only.

physpages[edit]

Total number of RAM pages used by processes in a container.

For memory pages used by several different containers (mappings of shared libraries, for example), only a fraction of a page is charged to each container. The sum of the physpages usage for all containers corresponds to the total number of pages used in the system by all containers.

For VSwap-enabled kernels, the barrier should be set to 0, and the limit limits the total size of RAM used by a container.

For older kernels, physpages is an accounting-only parameter. The barrier should be set to 0 and the limit to 'unlimited' (LONG_MAX).

numfile[edit]

Number of open files.

The barrier should be set equal to the limit. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only.

Note: actually currently adjusting the barrier will change the kernel behaviour on "pre-charging" the numfile resource. If you change one you will most likely not notice any changes in container behaviour at all. This ability was added for researching purposes purely.

numflock[edit]

Number of file locks.

The configuration of this parameter should have a gap between the barrier and the limit, as illustrated in UBC configuration examples.

Very high limits on numflock parameters and the big number of file locks in the system may cause certain slowdown of the whole system (but not fatal). So, the limits on this parameter should be reasonable, depending on the real requirements of the applications.

numpty[edit]

Number of pseudo-terminals.

This parameter is usually used to limit the number of simultaneous shell sessions. The barrier should be set equal to the limit. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only. However, in OpenVZ systems, the actual number of pseudo-terminals allowed for one container is limited to 256.

numsiginfo[edit]

Number of siginfo structures.

The size of the structure is also accounted into kmemsize. The default installations of stand-alone Linux systems limit this number to 1024 for the whole system. In OpenVZ installations, numsiginfo limit applies to each container individually.

The barrier should be set equal to the limit. Very high settings of the limit of this parameter may reduce responsiveness of the system. It is unlikely that any container will need the limit greater than the Linux default — 1024.

dcachesize[edit]

The total size of dentry and inode structures locked in memory.

Dcachesize parameter controls filesystem-related caches, such as directory entry (dentry) and inode caches. The value accounted into dcachesize is also included into kmemsize.

Dcachesize exists as a separate parameter to impose a limit causing file operations to sense memory shortage and return an error to applications, protecting from memory shortages during critical operations that shouldn't fail.

The configuration of this parameter should have a gap between the barrier and the limit, as illustrated in UBC configuration examples. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration affects functionality and resource shortage reaction of applications in the given container only.

numiptent[edit]

The number of NETFILTER (IP packet filtering) entries.

The barrier should be set equal to the limit. There is a restriction on the total number of numiptent. It depends on the amount of other allocations in so called “vmalloc” memory area and constitutes about 250000 entries. Violation of this restriction may cause failures of operations with IP packet filter tables (execution of iptables(8)) in any container or the host system, or failures of container starts.

Also, large numiptent cause considerable slowdown of processing of network packets. It is not recommended to allow containers to create more than 200–300 numiptent.

swappages[edit]

The amount of swap space to show in container.

Yellowpin.svg Note: this parameter is only available in RHEL5-based kernel since version 028stab060.2, in 2.6.27 since kiprensky.

The configuration of this parameter doesn't affect security and stability of the whole system or isolation between containers. Its configuration only affects the way OpenVZ kernel reports about available swap in a container. This is needed for some applications which refuse to run inside a container unless the kernel report that no less than some specific amount of swap is available.

If limit is set, its value is reported as the amount of total swap space in a container.

If the limit is set to LONG_MAX (which is the in-kernel default for this parameter), all the swap space values parameters (total, used, free) are reported as 0.

The value of barrier for this beancounter is ignored.

The value of held shows how much swap space is currently being used for this container.