UBC consistency check

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

System resource control parameters have certain interdependencies. Constraints on the parameter settings are listed below. Indexes bar and lim in the formulae below mean the barrier and the limit of the parameters, respectively.

Configuration of resource control parameters for a container is invalid if these constraints are not satisfied. The best way to ensure the validity of the configuration is to use the vzcfgvalidate(8) utility.

All the interdependencies discussed below and their importance are summarized in UBC interdependencies table.

The configured limits can be checked through

• /proc/user_beancounters interface;
• container configuration files in /etc/vz/conf/ directory.

kmemsize should be enough for the expected number of processes

$kmemsize_{bar}\geq 40KB\cdot avnumproc+dcachesize_{lim}$

(avnumproc here stands for the expected average number of processes).

This constraint is important for applications to work reliably in the container. If it is not satisfied, applications will start to fail in the middle of operations instead of failing while spawning more processes and the application's ability to handle resource shortage will be very limited.

Memory allocation limits should not be less than the guarantee

$privvmpages_{bar}\geq vmguarpages_{bar}$

If this constraint is not satisfied, vmguarpages will not work.

Send buffers should have enough space for all sockets

$tcpsndbuf_{lim}-tcpsndbuf_{bar}\geq 2.5KB\cdot numtcpsock$

$othersockbuf_{lim}-othersockbuf_{bar}\geq 2.5KB\cdot numothersock$

These constraints are also important. If they are not satisfied, transmission of data over the sockets may hang in some circumstances.

Other TCP socket buffers should be big enough

$tcprcvbuf_{lim}-tcprcvbuf_{bar}\geq 2.5KB\cdot numtcpsock$

$tcprcvbuf_{bar}\geq 64KB$

$tcpsndbuf_{bar}\geq 64KB$

Selecting the left side equal to the right side in the inequalities above ensures minimal performance of network communications. Increasing the left side will increase performance to a certain extent.

UDP socket buffers should be large enough if the system is not tight on memory

$dgramrcvbuf_{bar}\geq 129KB$

$othersockbuf_{bar}\geq 129KB$

These constraints are desired, but not essential. Large enough buffers for UDP sockets improve reliability of datagram delivery. However, note that if the UDP traffic is so bursty that it needs larger buffers, the datagrams will likely be lost not because of resource control limits, but because of other memory and performance limitations.

Number of files limit should be adequate for the expected number of processes

$numfile\geq avnumproc\cdot 32$

Note that each process after a execve(2) system call requires a file for each loaded shared library. A too low numfile limit will increase the chances of failures during execve(2) calls with error messages that are not clear to the users.

The limit on the total size of dentry and inode structures locked in memory should be adequate for allowed number of files

$dcachesize_{bar}\geq numfile\cdot 384\ {\rm {(bytes)}}$

A too low dcachesize limit will increase the chances of file operation refusals resulting in unexpected application failures.

Barrier should be less or equal than limit

In addition to the conditions listed above,

$barrier\leq limit$

should be maintained for each parameter.