Open main menu

OpenVZ Virtuozzo Containers Wiki β

Changes

UBC primary parameters

622 bytes added, 21:04, 1 October 2011
simplify toc
The most important parameters determining the resources available to
Virtual Environment container are explained below. The meaning of the parametersis illustrated assuming that the Virtual Environment container runs some network
server applications.
== numproc ==
Maximum number of processes and kernel-level threads allowed for this Virtual Environmentcontainer.
Many server applications (like Apache Web server, FTP and mail servers)
Configuring resource control system, it is important to estimate both
the maximum number of processes and the average number of processes
(referred to as <code>avnumproc </code> later). Other (dependent) resource
control parameters may depend both on the limit and the average number (see [[UBC consistency check]]).
Barrier The <code>barrier</code> of <code>numproc </code> doesn't provide additional control and should be set equal to the <code>limit</code>.
There is a restriction on the total number of processes in the system.
number of TCP connections and, thus, the number of clients the server
application can handle in parallel.
Barrier The <code>barrier</code> of this parameter should be set equal to the <code>limit</code>. If each Virtual Environment container has it's own set of IP addresses (which is
the only way a OpenVZ system can be configured), there are no direct
limits on the total number of TCP sockets in the system. The number
of sockes sockets needs to be controlled because each socket needs certain
amount of memory for receive and transmit buffers (see descriptions
of <code>[[tcpsndbuf]]</code> and <code>[[tcprcvbuf]]</code> below), and
the memory is a limited resource.
database server as a back-end) may need one or multiple local sockets
to serve each client. Straightforward applications (for example, most
mail servers, with the exception of Postfix) do not use local sockets.
UDP sockets are used for Domain Name Service (DNS) queries, but
(SNMP agents and others).
The <code>Barrierbarrier</code> of this parameter should be set equal to the <code>limit</code>.
The number of local sockets in a system is not limited. The number of
UDP sockets in a system, similarly to TCP sockets, is not limited in
more memory it needs.
The amount of memory that Virtual Environmentcontainer's applications areguaranteed to be able to allocate is specified as the <code>barrier </code> of
<code>vmguarpages</code> parameter. The current amount of allocated memory space
is accounted into <code>privvmpages</code> parameter, and <code>vmguarpages</code>
parameter does not have its own accounting. The <code>barrier </code> and the <code>limit </code> of
<code>privvmpages</code> parameter impose an upper limit on the memory allocations
(see [[{{PAGENAME}}#privvmpages|privvmpages]]). The meaning of the <code>limit</code> for the
<code>vmguarpages</code> parameter is unspecified in the current version and should be set
to the maximal allowed value ([[MAX_ULONGLONG_MAX]]).
If the current amount of allocated memory space does not exceed the
guaranteed amount (the <code>barrier</code> of <code>vmguarpages</code>),
memory allocations of Virtual Environmentcontainer's applications always succeed.
If the current amount of allocated memory space exceeds the guarantee but below
the <code>barrier</code> of <code>privvmpages</code>, allocations may or may not succeed,
made by the applications fail.
The memory allocation guarantee (<code>vmguarpages</code>) is a primary tool for
controlling the memory available to Virtual Environmentscontainers, because
it allows administrators to provide Service Level Agreements — agreements
guaranteeing certain quality of service, certain amount of resources
and general availability of the service. The unit of measurement
of vmguarpages values is memory pages (4KB on x86 and x86_64 processors).The total memory allocation guarantees given to Virtual Environmentscontainers
are limited by the physical resources of the computer — the size of RAM
and the swap space — as discussed in [[UBC systemwide configuration]].
 
There is a ''pseudo-graphical'' tool - <code>[http://en.dklab.ru/lib/dklab_vzmem/ vzmem]</code> - which allows you to distribute physical memory among all VEs consistently. It shows all physical memory blocks graphically in <code>/etc/vz/conf/MEM-MAP</code> text file and lets you to move these blocks from one VE to another to redistribute the memory. Also you may specify "additional" memory personally for each VE: such memory will be obtained from system's free memory or swap (it is reflected as modifying of <code>privvmpages</code> parameter).