6,534
edits
Changes
m
Virtual Environmentcontainer's processes, except the network buffers discussed below.
Virtual Environmentcontainer.
Virtual Environments containers with <code>oomguarpages</code> excess, applications in theVirtual Environment container with the biggest excess will be killed first.
== Units ==<code>Oomguarpages</code> and <code>privvmpages</code>values are measured in There's also an article describing how [[memory pageuser pages accounting]]s.For other secondary parameters, the values are in bytesworks.
== kmemsize ==
Size of unswappable memoryin bytes, allocated by the operating system kernel.
It includes all the kernel internal data structures associated with the
These data structures reside in the first gigabyte of the computer's RAM,
so called [[UBC systemwide configuration#“Low memory”|“low memory”]].
(for example, 10%, as in [[UBC configuration examples]]). Equal <code>barrier</code> and <code>limit</code> of
the <code>kmemsize</code> parameter may lead to the situation where the kernel will
need to kill Virtual Environmentcontainer's applications to keep the <code>kmemsize</code>
usage under the limit.
<code>Kmemsize</code> limits can't be set arbitrarily high.
The total amount of <code>kmemsize</code> consumable by all Virtual Environmentscontainers
in the system plus the socket buffer space (see below) is limited by the
hardware resources of the system.
do not have strong negative effect on the applications, but just reduce
performance of network communications.
If you use rtorrent in a container, a low value for <code>tcpsndbuf</code> may cause rtorrent to take unusual amount of cpu. In this case, you must put a higher value. Also watch the number of failcnt in /proc/user_beancounters.
<code>Tcpsndbuf</code> limits can't be set arbitrarily high.
The total amount of <code>tcpsndbuf</code> consumable by all Virtual Environmentscontainers
in the system plus the <code>kmemsize</code> and other socket buffers is limited
by the hardware resources of the system.
<code>Tcprcvbuf</code> limits can't be set arbitrarily high.
The total amount of <code>tcprcvbuf</code> consumable by all Virtual Environmentscontainers
in the system plus the <code>kmemsize</code> and other socket buffers is limited
by the hardware resources of the system.
<code>Othersockbuf</code> configuration should satisfy
<math>othersockbuf_{lim} - othersockbuf_{bar} \ge 2.5KB \cdot numothersock.</math>
Increased limit for <code>othersockbuf</code> is necessary for high performance of
<code>Othersockbuf</code> limits can't be set arbitrarily high.
The total amount of <code>othersockbuf</code> consumable by all Virtual Environmentscontainers
in the system plus the <code>kmemsize</code> and other socket buffers
is limited by the hardware resources of the system.
<code>Dgramrcvbuf</code> limits usually don't need to be high.
Only if the Virtual Environments containers needs to send and receive very large
datagrams, the <code>barrier</code>s for both <code>othersockbuf</code> and
<code>dgramrcvbuf</code> parameters should be raised.
<code>Dgramrcvbuf</code> limits can't be set arbitrarily high.
The total amount of <code>dgramrcvbuf</code> consumable by all Virtual Environmentscontainers
in the system plus the <code>kmemsize</code> and other socket buffers
is limited by the hardware resources of the system.
If applications start to consume more memory than the computer has,
the system faces an out-of-memory condition.
In this case the operating system will start to kill Virtual Environmentcontainer's
processes to free some memory and prevent the total death
of the system. Although it happens very rarely in typical system loads,
killing processes in out-of-memory situations is a normal reaction of the
system, and it is built into every Linux kernel<ref>The possible reasonsof out-of-memory situations are the excess of total<code>[[vmguarpages]]</code> guarantees the available physical resources or high memoryconsumption by system processes. Also, the kernel might allow someVirtual Environments containers to allocate memory above their <code>[[vmguarpages]]</code>guarantees when the system had a lot of free memory, and later, when otherVirtual Environments containers claim their guarantees, the system will experience thememory shortage.</ref>.
<code>[[Oomguarpages]]</code> parameter accounts the total amount of
memory and swap space used by the processes of a particular
The <code>barrier</code> of the <code>oomguarpages</code> parameter is the out-of-memory
guarantee.
(the value of <code>oomguarpages</code>) plus the amount of used kernel memory
(<code>[[kmemsize]]</code>) and socket buffers is below the <code>barrier</code>,
processes in this Virtual Environment container are guaranteed not to be killed in
out-of-memory situations.
If the system is in out-of-memory situation and there are several
The <code>failcnt</code> counter of <code>oomguarpages</code> parameter
increases when a process in this Virtual Environment container is killed because
of out-of-memory situation.
the utilization of the hardware.
The meaning of the <code>limit</code>limit for the <code>oomguarpages</code> parameter is
unspecified in the current version.
The total out-of-memory guarantees given to the Virtual Environments containers should
not exceed the physical capacity of the computer, as discussed in [[UBC systemwide configuration#Memory and swap space]].
If guarantees are given for more than the system has, in out-of-memory
situations applications in Virtual Environments containers with guaranteed level of
service and system daemons may be killed.
== privvmpages ==
Memory allocation limitin [[Memory_page|pages]] (which are typically 4096 bytes in size).
<code>Privvmpages</code> parameter
The <code>barrier</code> and the <code>limit</code> of <code>privvmpages</code> parameter
control the upper boundary of the total size of allocated memory.
Note that this upper boundary doesn't guarantee that the Virtual Environmentcontainer
will be able to allocate that much memory, neither does it guarantee that
other Virtual Environments containers will be able to allocate their fair share of
memory.
The primary mechanism to control memory allocation is the <code>[[vmguarpages]]</code>
not used yet) memory.
The accounted value is an estimation how much memory will be really consumed
when the Virtual Environmentcontainer's applications start to use the allocated
memory.
Consumed memory is accounted into <code>[[oomguarpages]]</code> parameter.
Since the memory accounted into <code>privvmpages</code> may not be actually used,
the sum of current <code>privvmpages</code> values for all Virtual Environmentscontainers
may exceed the RAM and swap size of the computer.
This gap will be used for “high-priority” memory allocations, such
as process stack expansion.
Normal priority allocations will fail when the <code>barrier</code> ifof
<code>privvmpages</code> is reached.
Total <code>privvmpages</code> should match correlate with the physical resources of the
computer.
Also, it is important not to allow any Virtual Environment container to allocate a
significant portion of all system RAM to avoid serious service level
degradation for other VEscontainers.
Both these configuration requirements are discussed in [[UBC systemwide configuration#Allocated memory]].
== System-wide limits ==
in [[UBC systemwide configuration]].
Those restrictions are very important, because their violation may
allow any Virtual Environment container cause the whole system to hang. == Notes ==<references/>
