Changes

Size of unswappable memoryin bytes, allocated by the operating system kernel.

Virtual Environmentcontainer's processes, except the network buffers discussed below.

(for example, 10%, as in [[UBC configuration examples]]). Equal <code>barrier</code> and <code>limit</code> of

need to kill Virtual Environmentcontainer's applications to keep the <code>kmemsize</code>

The total amount of <code>kmemsize</code> consumable by all Virtual Environmentscontainers

The total amount of <code>tcpsndbuf</code> consumable by all Virtual Environmentscontainers

The total amount of <code>tcprcvbuf</code> consumable by all Virtual Environmentscontainers

<math>othersockbuf_{lim} - othersockbuf_{bar} \ge 2.5KB \cdot numothersock.</math>

The total amount of <code>othersockbuf</code> consumable by all Virtual Environmentscontainers

Only if the Virtual Environments containers needs to send and receive very large

The total amount of <code>dgramrcvbuf</code> consumable by all Virtual Environmentscontainers

FIXMEThe guaranteed amount of memory for the case the memory is “over-booked”(out-of-memory kill guarantee). <code>Oomguarpages</code> parameter is related to <code>[[vmguarpages]]</code>.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 container'sprocesses to free some memory and prevent the total deathof the system. Although it happens very rarely in typical system loads,killing processes in out-of-memory situations is a normal reaction of thesystem, and it is built into every Linux kernel<ref>The possible reasons of out-of-memory situations are the excess of total <code>[[vmguarpages]]</code> guarantees the available physical resources or high memory consumption by system processes. Also, the kernel might allow some containers to allocate memory above their <code>[[vmguarpages]]</code> guarantees when the system had a lot of free memory, and later, when other containers claim their guarantees, the system will experience the memory shortage.</ref>. <code>[[Oomguarpages]]</code> parameter accounts the total amount ofmemory and swap space used by the processes of a particularcontainer.The <code>barrier</code> of the <code>oomguarpages</code> parameter is the out-of-memoryguarantee. If the current usage of memory and swap space(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 container are guaranteed not to be killed inout-of-memory situations.If the system is in out-of-memory situation and there are severalcontainers with <code>oomguarpages</code> excess, applications in thecontainer with the biggest excess will be killed first.The <code>failcnt</code> counter of <code>oomguarpages</code> parameterincreases when a process in this container is killed becauseof out-of-memory situation. If the administrator needs to make sure that some application won't beforcedly killed regardless of the application's behavior,setting the <code>[[privvmpages]]</code> limit to a value not greater than the<code>oomguarpages</code> guarantee significantly reduce the likelihood ofthe application being killed,and setting it to a half of the <code>oomguarpages</code> guarantee completelyprevents it.Such configurations are not popular because they significantly reducethe utilization of the hardware. The meaning of the <code>limit</code> for the <code>oomguarpages</code> parameter isunspecified in the current version. The total out-of-memory guarantees given to the containers shouldnot 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-memorysituations applications in containers with guaranteed level ofservice and system daemons may be killed.

FIXMEMemory allocation limit in [[Memory_page|pages]] (which are typically 4096 bytes in size). <code>Privvmpages</code> parameterallows controlling the amount of memory allocated by applications. The <code>barrier</code> and the <code>limit</code> of <code>privvmpages</code> parametercontrol the upper boundary of the total size of allocated memory.Note that this upper boundary doesn't guarantee that the containerwill be able to allocate that much memory, neither does it guarantee thatother containers will be able to allocate their fair share ofmemory.The primary mechanism to control memory allocation is the <code>[[vmguarpages]]</code>guarantee. <code>Privvmpages</code> parameter accounts allocated (but, possibly,not used yet) memory.The accounted value is an estimation how much memory will be really consumedwhen the container's applications start to use the allocatedmemory.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 containersmay exceed the RAM and swap size of the computer. There should be a safety gap between the <code>barrier</code> and the <code>limit</code>for <code>privvmpages</code> parameter to reduce the number of memory allocationfailures that the application is unable to handle.This gap will be used for “high-priority” memory allocations, suchas process stack expansion.Normal priority allocations will fail when the <code>barrier</code> of<code>privvmpages</code> is reached. Total <code>privvmpages</code> should correlate with the physical resources of thecomputer.Also, it is important not to allow any container to allocate asignificant portion of all system RAM to avoid serious service leveldegradation for other containers.Both these configuration requirements are discussed in [[UBC systemwide configuration#Allocated memory]]. There's also an article describing how [[user pages accounting]] works. == System-wide limits ==All secondary parameters are related to memory.Total limits on memory-related parameters must not exceed the physicalresources of the computer.The restrictions on the configuration of memory-related parameters are listedin [[UBC systemwide configuration]].Those restrictions are very important, because their violation mayallow any container cause the whole system to hang. == Notes ==<references/>