UBC auxiliary parameters
|
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 Virtual Environment 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 Virtual Environment. Failures or misbehavior of one application inside a Virtual Environment 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 Virtual Environment.
- These parameters may be used to impose some administrative limits on the Virtual Environment (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
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 Virtual Environments. Its configuration affects functionality and resource shortage reaction of applications in the given Virtual Environment only.
shmpages
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 Virtual Environments.
Its configuration affects functionality and resource shortage reaction
of applications in the given Virtual Environment only.
physpages
Total number of RAM pages used by processes in this Virtual Environment.
For memory pages used by several different Virtual Environments (mappings of
shared libraries, for example), only a fraction of a page is charged to each
Virtual Environment.
The sum of the physpages usage for all Virtual Environments
corresponds to the total number of pages used in the system by all
Virtual Environments.
Physpages is an accounting-only parameter currently.
In future OpenVZ releases, this parameter will allow to provide guaranteed
amount of application memory, residing in RAM and not swappable.
For compatibility with future versions, the barrier of this
parameter should be set to 0 and the limit to
the maximal allowed value (MAX_ULONG).
numfile
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 Virtual Environments.
Its configuration affects functionality and resource shortage reaction
of applications in the given Virtual Environment only.
numflock
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
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 Virtual Environments.
Its configuration affects functionality and resource shortage reaction
of applications in the given Virtual Environment only.
However, in OpenVZ systems, the actual number of pseudo-terminals allowed
for one Virtual Environment is limited to 256.
numsiginfo
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
Virtual Environment 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 Virtual Environment will need the limit greater than
the Linux default — 1024.
dcachesize
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 Virtual Environments.
Its configuration affects functionality and resource shortage reaction
of applications in the given Virtual Environment only.
numiptent
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 Virtual Environment or the host system,
or failures of Virtual Environment starts.
Also, large numiptent cause considerable slowdown of processing
of network packets. It is not recommended to allow Virtual Environments
to create more than 200–300 numiptent.