6,534
edits
Changes
Added "Allocated memory"
But administrators should not guarantee Virtual Environment more
than the system actually has.
== Allocated memory ==
This subsection considers standard memory allocations made by
applications in the Virtual Environment.
The allocations for each Virtual Environment are controlled by
two parameters: <code>vmguarpages</code> and <code>privvmpages</code>,
discussed in sections FIXME.
Allocated memory is a more “virtual” system resource than the RAM or RAM
plus swap size.
Applications can allocate memory but start to use it only later, and
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 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\ VE}
(privvmpages_{cur}\cdot4096+
kmemsize_{cur}+allsocketbuf_{cur})}
{RAM\ size + swap\ size}\rm.
</math>
This utilization level is the ratio of the amount of allocated memory
to the capacity of the system.
Low utilization level means that the system can support more
Virtual Environments, if other resources permit.
High utilization levels may, but doesn't necessarily mean that
the system is overloaded.
As it was explaned above, not all applications use all the allocated memory,
so this utilization level may exceed <math>1</math>.
Computing this utilization level is useful for comparing
it with the commitment level and the level of memory allocation restrictions,
discussed below, to configure memory allocation restrictions
for the Virtual Environment.
== Commitment level ==
Allocation guarantee commitment level
<math>
\frac{\displaystyle\sum_{all\ VE}
(vmguarpages_{bar}\cdot4096+
kmemsize_{lim}+allsocketbuf_{lim})}
{RAM\ size + swap\ size}
</math>
is the ratio of the memory space guaranteed to be available for
allocations to the capacity of the system.
Similarly to the commitment level of memory plus swap space (as discussed
in subsection [[{{PAGENAME}#Memory and swap space|Memory and swap space]]),
this level should be kept below <math>1</math>.
If the level is above <math>1</math>, it significantly increases the chances of
applications to be killed instead of be notified in case the system
experiences a memory shortage.
It's better to provide lower guarantees than accidently guarantee more than
the system has, because Virtual Environments 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 with
preferred service.
=== Limiting memory allocations ===
In addition to providing allocation guarantees, it is possible
to impose restrictions on the amount of memory allocated by
Virtual Environments.
If a system has multiple Virtual Environments,
it is important to make sure that for each Virtual Environment
<math>privvmpages_{lim}\cdot4096 \le 0.6\cdot {RAM\ size}\rm.</math>
If this condition is not satisfied, a single Virtual Environment may easily
cause an excessive swap-out and very bad performance of the whole system.
Usually, for each Virtual Environment <code>privvmpages</code> limitations are
to values much less than the size of the RAM.
The resource control parameters should be configured in a way,
so that in case of memory shortage applications are given chance
to notice the shortage and exit gracefully, instead of being terminated
by the kernel.
For this purpose, it is recommended to maintain reasonable
total level of memory allocation restrictions, computed as
<math>
\frac{\displaystyle\sum_{all\ VE}
(privvmpages_{lim}\cdot4096+
kmemsize_{lim}+allsocketbuf_{lim})}
{swap\ size}\rm.
</math>
This number shows how much memory applications are allowed to allocate
in comparison with the capacity of the system.
In practice, a lot of applications do not use the memory very efficiently
and, sometimes, allocated memory will never be used later.
For example, Apache Web server at start time it allocates about
20–30%% more memory that it will ever use.
Some multi-threaded applications are especially bad at using their memory,
and their rate of allocated to used memory may happen to be 1000%.
The bigger the level of memory allocation restrictions,
the more chances are that applications will be killed instead
of getting an error on next memory allocation in case
the system experiences memory shortage.
The levels ranging in <math>1.5</math>–<math>4</math> can be considered acceptable.
Administrators can find experimentally the optimal setting for their load,
basing on the frequency of messages “Out of Memory: killing process”
in system logs, saved by <code>klogd(8)</code> and <code>syslogd(8)</code>.
However, for stability-critical applications, it's better to keep
the level not exceeding <math>1</math>.
