Editing UBC auxiliary parameters

{{UBC toc}}

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.
<ul>
<li>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.
</li>

<li>
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.
</li>

<li>
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]]).
</li>
</ul>

So, auxiliary parameters play a role similar to limits imposed by
<code>setrlimit(2)</code> interface and limits configurable by
<code>sysctl(8)</code> 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 ==
Process pages not allowed to be swapped out (pages locked by <code>mlock(2)</code>).

The size of these pages is also accounted into <code>[[kmemsize]]</code>.
The <code>barrier</code> may be set equal to the <code>limit</code> or may allow
some gap between the <code>barrier</code> and the <code>limit</code>, 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 ==
The total size of shared memory (IPC, shared anonymous mappings and
<code>tmpfs</code> objects).

These pages are also accounted into <code>[[privvmpages]]</code>.

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.

== 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.

Please visit my 










Regards

== 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.
@@ Line 170: / Line 170: @@
 of applications in the given container only.
-== numiptent ==
+Please visit my
-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>.
+Regards
 == swappages ==