UBC Parameters: OpenVZ

Primary Parameters

• avnumproc - The average number of processes and threads.
• numproc - The maximum number of processes and threads the VE may create. The barrier of
numproc doesn't provide additional control and should be set equal to the limit.
• numtcpsock - This parameter limits the number of TCP connections with a VPS
The barrier of this parameter should be set equal to the limit.
• numothersock – This parameter limits the number of sockets other than TCP, like UDP.
The barrier of this parameter should be set equal to the limit. The number of local sockets in
a system is not limited.
• vmguarpages - VE applications are guaranteed to be able to allocate additional memory; as
long as the amount of memory accounted as privvmpages does not exceed the configured
vmguarpages parameter. Above this barrier, additional memory allocation is not guaranteed
and may fail in case of overall memory shortage.
The amount of memory that container's applications are guaranteed to be able to allocate is
specified as the barrier of vmguarpages parameter, and the limit for the vmguarpages
parameter is unspecified in the current version and should be set to the maximal allowed
value.

Secondary Parameters

• kmemsize – When allowing a container access to a certain amount of memory, not all of it
will be used in the same way. kmemsize is the amount of bytes that will be used for kernel
activity of that specific container. Equal barrier and limit of the kmemsize parameter may
lead to the situation where the kernel will need to kill container's applications to keep the
kmemsize usage under the limit.
• tcpsndbuf - The kernel memory allocated to buffer the data sent from an application to
remote side but not acknowledged yet.
• tcprcvbuf - The kernel memory allocated to buffer the data received from remote , but not
yet read by local application.
• othersockbuf – This parameter defines total size of UDP socket buffers.
• dgramrcvbuf – The parameter define total size of received UDP buffers. For dgramrcvbuf
the barrier should be set to the limit.
• oomguarpages - This limit defines cuase the OOM errors with the VE. The out-of-memory
a VE process will not be killed even in case of heavy memory shortage if the current
memory consumption does not reach the oomguarpages barrier.

Auxiliary Parameters

• lockedpages - The memory not allowed to be swapped out (locked with the mlock() system
call), in pages. The barrier may be set equal to the limit or may allow some gap between the
barrier and the limit.
• shmpages - The total size of shared memory allocated by the process of a particular VE.
The barrier should be set equal to the limit.
• privvmpages - The size of private memory allocated by an application. This memory is
always shared among different applications, and it is not included in this resource parameter.
• numfile - The number of files opened by all VE processes. The barrier should be set equal to
the limit.
• numflock - The number of file locks created by all VE processes. This parameter should
have a gap between the barrier and the limit.
• numpty - The number of pseudo-terminals, such as an ssh session, the screen or xterm
applications, etc. The barrier should be set equal to the limit.
• numsiginfo - The number of siginfo structures,this parameter limits the size of the signal
delivery queue. The barrier should be set equal to the limit.
• dcachesize – This value determines the inode limit with the VE.
• physpages - The total size of ram used by the VE processes. This is an accounting-only
parameter currently. It shows the usage of RAM by the VE. 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'.
• numiptent - The number of IP packet filtering entries. The barrier should be set equal to the
limit.

Limits and Barriers

The meaning of barrier and limit is parameter-dependant; in short, those can be thought of as a soft
limit and a hard limit. If any resource hits the limit, the corresponding fail counter will be increased.
For all parameters the barrier should not be greater than the limit. If the resource usage exceeds the
barrier but doesn't exceed the limit, vital operations are still allowed to allocate new resources, and
other ones are not allowed. A gap between the barrier and the limit gives applications better chances
to handle resource shortage gracefully.Please find the snippet from a sample conguration below.
---------------------------------------------------------------------
# UBC parameters (in form of barrier: limit)
# Primary parameters
NUMPROC = "128:128"
AVNUMPROC = "64:64"
NUMTCPSOCK = "288:288"
NUMOTHERSOCK = "288:288"
VMGUARPAGES = "98304:9223372036854775807"
# Secondary parameters
KMEMSIZE = "15523666:17076032"
TCPSNDBUF = "2449232:3598712"
TCPRCVBUF = "2449232:3598712"
OTHERSOCKBUF = "844366:1481926"
DGRAMRCVBUF = "844366:844366"
OOMGUARPAGES = "98304:9223372036854775807"
PRIVVMPAGES = "196608:204800"
# Auxiliary parameters
LOCKEDPAGES = "344:344"
SHMPAGES = "19567:19567"
PHYSPAGES = "0:9223372036854775807"
Numfile = "4256:4256"
NUMFLOCK = "224:246"
Numpty = "16:16"
NUMSIGINFO = "512:512"
DCACHESIZE = "2254786:2322430"
NUMIPTENT = "64:64"
--------------------------------------------------------------------------------------
Note: privvmpages show allocated (some of which might not be used), whereas oomguarpages
show allocated, all of which are used.