Editing UBC auxiliary parameters

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
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 container
+
connection consume certain resources. When the Virtual Environment
 
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 container. Failures or misbehavior of one application
+
same Virtual Environment. Failures or misbehavior of one application
inside a container is more likely to cause hitting a
+
inside a Virtual Environment 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 container.
+
long-running application inside the same Virtual Environment.
 
</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 container (for example, to not allow the user to run
+
on the Virtual Environment (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 containers.
+
stability of the whole system or isolation between Virtual Environments.
 
Its configuration affects functionality and resource shortage reaction
 
Its configuration affects functionality and resource shortage reaction
of applications in the given container only.
+
of applications in the given Virtual Environment 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 containers.
+
stability of the whole system or isolation between Virtual Environments.
 
Its configuration affects functionality and resource shortage reaction
 
Its configuration affects functionality and resource shortage reaction
of applications in the given container only.
+
of applications in the given Virtual Environment only.
 
 
== physpages ==
 
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 <code>physpages</code> usage for all containers
 
corresponds to the total number of pages used in the system by all
 
containers.
 
 
 
For [[VSwap]]-enabled kernels, the <code>barrier</code> should be set to 0,
 
and the <code>limit</code> limits the total size of RAM used by a container.
 
 
 
For older kernels, <code>physpages</code> is an accounting-only parameter.
 
The <code>barrier</code> should be set to <code>0</code> and the
 
<code>limit</code> to 'unlimited' ([[LONG_MAX]]).
 
 
 
== numfile ==
 
Number of open files.
 
 
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
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 <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 ==
 
Number of file locks.
 
 
 
The configuration of this parameter should have a
 
gap between the <code>barrier</code> and the <code>limit</code>, as illustrated in
 
[[UBC configuration examples]].
 
 
 
Very high limits on <code>numflock</code> 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 ==
 
Number of pseudo-terminals.
 
 
 
This parameter is usually used to limit the number of simultaneous shell
 
sessions.
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
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 <code>256</code>.
 
 
 
== numsiginfo ==
 
Number of <code>siginfo</code> structures.
 
 
 
The size of the structure is also accounted into <code>[[kmemsize]]</code>.
 
The default installations of stand-alone Linux systems limit this number
 
to <code>1024</code> for the whole system.
 
In OpenVZ installations, <code>numsiginfo</code> limit applies to each
 
container individually.
 
 
 
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
 
responsiveness of the system.
 
It is unlikely that any container will need the limit greater than
 
the Linux default — <code>1024</code>.
 
 
 
== dcachesize ==
 
The total size of <code>dentry</code> and <code>inode</code> structures locked in memory.
 
 
 
<code>Dcachesize</code> parameter controls filesystem-related caches, such as
 
directory entry (<code>dentry</code>) and inode caches.
 
The value accounted into <code>dcachesize</code> is also included into
 
<code>[[kmemsize]]</code>.
 
 
 
<code>Dcachesize</code> 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 <code>barrier</code> and the <code>limit</code>, 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 ==
 
The number of NETFILTER (IP packet filtering) entries.
 
 
 
The <code>barrier</code> should be set equal to the <code>limit</code>.
 
There is a restriction on the total number of <code>numiptent</code>.
 
It depends on the amount of other allocations in so called “vmalloc”
 
memory area and constitutes about <code>250000</code> entries.
 
Violation of this restriction may cause failures of operations with
 
IP packet filter tables (execution of <code>iptables(8)</code>)
 
in any container or the host system,
 
or failures of container starts.
 
 
 
Also, large <code>numiptent</code> cause considerable slowdown of processing
 
of network packets.  It is not recommended to allow containers
 
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.
 

Please note that all contributions to OpenVZ Virtuozzo Containers Wiki may be edited, altered, or removed by other contributors. If you don't want your writing to be edited mercilessly, then don't submit it here.
If you are going to add external links to an article, read the External links policy first!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)

Templates used on this page: