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.

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.