2,253
edits
Changes
m
Virtual Environments containers at the given time.
Virtual Environmentscontainers. Low commitment levels mean that the systemis capable of supporting more Virtual Environmentscontainers.
Virtual Environments containers are promised more resources
Virtual Environments containers is the memory used by system daemons
Virtual Environmentscontainers, if other resources permit.
Virtual Environmentscontainers.
Robot: Automated text replacement (-Virtual Environment +container)
The [[UBC consistency check]] article discussed validation of a resource control configuration
for a single Virtual Environmentcontainer. This article discusses checks that the 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
'''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 Virtual
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 Virtual
Environments 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.
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 level
increased, to about <math>1.5</math>—<math>2</math> for 400 containers.
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>
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.
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.
inaccessible by <code>ssh(1)</code> and lose other important functionality.
It is better to guarantee Virtual Environments containers less and have less commitment
levels than to accidently 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 normal
if memory and swap usage for some 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.
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 ===
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.