6,534
edits
Changes
link to vzmemcheck
{{UBC toc}}
The [[UBC consistency check]] article discussed validation of a resource control [[UBC]] configurationfor a single Virtual Environmentcontainer. This article discusses checks that the UBC configuration of the
'''whole''' system is '''valid'''.
Configurations where resources allowed for Virtual Environments containers exceed system
capacity<ref>More precisely, configurations with excessive
overcommitment, as explained below.</ref> are not valid
The best way to make sure that the configuration of the whole system
is valid is to run periodic automatic checks, based on the formulae described
below. {{Man|vzmemcheck|8}} utility can be helpful in calculations.
== Resource utilization and commitment level ==
'''Utilization''' shows the amount of resources consumed by all
In general, low utilization values mean that the system is under-utilized.
Often, it means that the system is capable of supporting more VirtualcontainersEnvironment if the existing VEs containers continue to maintain
the same load and resource consumption level.
High utilization values (in general, more than <code>1</code>)
mean the the system is overloaded and the service level
of the Virtual Environments containers is degraded.
'''Commitment level''' shows how much resources are “promised” to the existing
Commitment levels more than <code>1</code> mean that the
than the system has, and in this case the system is said to be
overcommitted.
If the system runs a lot of Virtual Environmentscontainers,it is usually acceptable to have some overcommitment, because it is unlikely that all VirtualEnvironments containers will request resources at the same time.
However, higher commitment levels (as discussed below for each resource
individually) will cause Virtual Environmentss containerss to experience failures to
allocate and use the resources promised to them.
== “Low memory” (x86_32 specific) ==Because of specifics of architecture of Intel's x86 processors, the RAM of the
computer can't be used uniformly.
The most important memory area is so called “low memory”, a part of memory
(or, if the computer has less RAM than 832MB, the size of the RAM).
Note that 64-bit kernels (i.e. x86_64, ia64 etc.) can access all memory
directly and are not using “low memory” area.
=== Utilization ===
The lower bound estimation of low memory utilization is
<math>
\frac{\displaystyle\sum_{all\ VEcontainers}
(kmemsize_{cur}+allsocketbuf_{cur})}
{0.4\cdot\min(RAM\ size, {\rm 832MB})}\rm,
<math>
\frac{\displaystyle\sum_{all\ VEcontainers}
(kmemsize_{lim}+allsocketbuf_{lim})}
{0.4\cdot\min(RAM\ size, {\rm 832MB})}\rm.
Commitment levels below <math>1</math> are normal.
Levels between <math>1</math> and <math>1.2</math> are usually acceptable for systems with about
100 Virtual Environmentscontainers.Systems with more Virtual Environments containers may have the commitment levelincreased, to about <math>1.5</math>—<math>2</math> for 400 VEscontainers.
Higher commitment levels for this resource are not recommended,
because the consequences of exceeding the low memory capacities
are severe and affect the whole system and all the Virtual Environmentscontainers.
== Total RAM ==
=== Utilization ===
The amount of RAM consumed by all Virtual Environments containers can be computed as
<math>
\sum_{all\ VEcontainers}
(physpages_{cur}\cdot4096+kmemsize_{cur}+allsocketbuf_{cur})\rm.
</math>
The difference between memory usage shown by <code>free(1)</code>
or <code>/proc/meminfo</code> and the total amount of RAM consumed by
and different caches.
<math>
\frac{\displaystyle\sum_{all\ VEcontainers}
(physpages_{cur}\cdot4096+
kmemsize_{cur}+allsocketbuf_{cur})}
Lower utilization means that the system is under-utilized, and,
if other system resources and their commitment levels permit,
the system can host more Virtual Environmentscontainers.
By the nature of the accounting of <code>physpages</code> and other parameters,
total RAM utilization can't be bigger than <math>1</math>.
However, if this activity is not excessive, the performance decrease is not
very noticeable. On the other hand, the benefits of using swap space are
quite big, allowing to increase the number of Virtual Environments containers in the
system about 2 times.
=== Utilization ===
<math>
\frac{\displaystyle\sum_{all\ VEcontainers}
(oomguarpages_{cur}\cdot4096+
kmemsize_{cur}+allsocketbuf_{cur})}
=== Commitment level ===
<math>
\frac{\displaystyle\sum_{all\ VEcontainers}
(oomguarpages_{bar}\cdot4096+
kmemsize_{lim}+allsocketbuf_{lim})}
The normal commitment level is about <math>0.8</math>—<math>1</math>.
Commitment levels more than <math>1</math> means that the Virtual Environmens containers are
guaranteed more memory than the system has.
Such overcommitment is strongly not recommended, because in that case
inaccessible by <code>ssh(1)</code> and lose other important functionality.
It is better to guarantee Virtual Environments containers less and have less commitmentlevels than to accidently accidentally overcommit the system by memory plus swap.If the system has spare memory and swap, Virtual Environments containers will
transparently be able to use the memory and swap above their guarantees.
Guarantees given to Virtual Environments containers should not be big, and it is normalif memory and swap usage for some VEs containers stays above their
guarantee.
It is also normal to give guarantees only to Virtual Environments containers with
preferred service.
But administrators should not guarantee Virtual Environment container more
than the system actually has.
This subsection considers standard memory allocations made by
applications in the Virtual Environmentcontainer.The allocations for each Virtual Environment container are controlled by
two parameters: <code>vmguarpages</code> and <code>privvmpages</code>,
discussed in sections FIXME.
the amount of system's free memory will decrease only at the moment of the
use.
The sum of allocated memory size of all Virtual Environments containers is an estimation
of how much physical memory will be used when (and if) all applications
claim the allocated memory.
=== Utilization ===
<math>
\frac{\displaystyle\sum_{all\ VEcontainers}
(privvmpages_{cur}\cdot4096+
kmemsize_{cur}+allsocketbuf_{cur})}
Low utilization level means that the system can support more
High utilization levels may, but doesn't necessarily mean that
the system is overloaded.
it with the commitment level and the level of memory allocation restrictions,
discussed below, to configure memory allocation restrictions
for the Virtual Environmentcontainer.
=== Commitment level ===
<math>
\frac{\displaystyle\sum_{all\ VEcontainers}
(vmguarpages_{bar}\cdot4096+
kmemsize_{lim}+allsocketbuf_{lim})}
It's better to provide lower guarantees than accidently guarantee more than
the system has, because Virtual Environments containers are allowed to allocated memory
above their guarantee if the system is not tight on memory.
It is also normal to give guarantees only to Virtual Environments containers with
preferred service.
In addition to providing allocation guarantees, it is possible
to impose restrictions on the amount of memory allocated by
If a system has multiple Virtual Environmentscontainers,it is important to make sure that for each Virtual Environmentcontainer
<math>privvmpages_{lim}\cdot4096 \le 0.6\cdot {RAM\ size}\rm.</math>
If this condition is not satisfied, a single Virtual Environment container may easily
cause an excessive swap-out and very bad performance of the whole system.
Usually, for each Virtual Environment container <code>privvmpages</code> limitations are
to values much less than the size of the RAM.
<math>
\frac{\displaystyle\sum_{all\ VEcontainers}
(privvmpages_{lim}\cdot4096+
kmemsize_{lim}+allsocketbuf_{lim})}
{RAM\ size + swap\ size}\rm.
</math>
However, for stability-critical applications, it's better to keep
the level not exceeding <math>1</math>.
<references/>