Difference between revisions of "UBC auxiliary parameters"
(add swappages description) |
m (Reverted edits by 109.228.171.118 (talk) to last revision by Kir) |
||
(12 intermediate revisions by 5 users not shown) | |||
Line 4: | Line 4: | ||
important for security and stability of the whole system. Auxiliary | important for security and stability of the whole system. Auxiliary | ||
parameters differ much from primary and secondary parameters in this respect. | parameters differ much from primary and secondary parameters in this respect. | ||
− | |||
− | |||
The primary functions of auxiliary parameters are the following. | The primary functions of auxiliary parameters are the following. | ||
Line 83: | Line 81: | ||
== physpages == | == physpages == | ||
− | Total number of RAM pages used by processes in | + | Total number of RAM pages used by processes in a container. |
For memory pages used by several different containers (mappings of | For memory pages used by several different containers (mappings of | ||
Line 92: | Line 90: | ||
containers. | containers. | ||
− | <code> | + | 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 == | == numfile == | ||
Line 192: | Line 190: | ||
The amount of swap space to show in container. | The amount of swap space to show in container. | ||
− | {{Note|this parameter is only available in RHEL5-based kernel since version 028stab060.2.}} | + | {{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 | The configuration of this parameter doesn't affect security and | ||
Line 204: | Line 202: | ||
of total swap space in a container. | of total swap space in a container. | ||
− | If the <code>limit</code> is set to [[ | + | If the <code>limit</code> is set to [[LONG_MAX]] (which is the |
in-kernel default for this parameter), all the swap space values | in-kernel default for this parameter), all the swap space values | ||
parameters (total, used, free) are reported as 0. | parameters (total, used, free) are reported as 0. | ||
Line 210: | Line 208: | ||
The value of <code>barrier</code> for this beancounter is ignored. | The value of <code>barrier</code> for this beancounter is ignored. | ||
− | The <code | + | 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
|
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.
Contents
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.
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.