UBC auxiliary parameters

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.

Introduction

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

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

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

Total number of RAM pages used by processes in this 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.

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 containers. Its configuration affects functionality and resource shortage reaction of applications in the given container 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 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

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

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

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.