3.6. Managing Container Memory Parameters¶
This section describes the VSwap memory management system. You will learn to do the following:
- Configure the main VSwap parameters for containers.
- Set the memory allocation limit in containers.
- Configure OOM killer behavior.
- Enhance the VSwap functionality.
3.6.1. Configuring Main VSwap Parameters¶
Virtuozzo Hybrid Server utilizes the VSwap scheme for managing memory-related parameters in containers. Like many other memory management schemes used on standalone Linux computers, this scheme is based on two main parameters:
RAMdetermines the total size of RAM that can be used by the processes of a container.
swapdetermines the total size of swap that can be used by a container for swapping out memory once the RAM is exceeded.
The memory management scheme works as follows:
- You set for a container a certain amount of RAM and swap space that can be used by the processes running in the container.
- When the container exceeds the RAM limit set for it, the swapping process starts. The swapping process for containers slightly differs from that on a standalone computer. The container swap file is virtual and, if possible, resides in the Node RAM. In other words, when the swap-out for a container starts and the Node has enough RAM to keep the swap file, the swap file is stored in the Node RAM rather than on the hard drive.
- Once the container exceeds its swap limit, the system invokes the OOM Killer for this container.
- The OOM Killer chooses one or more processes running in the affected container and forcibly kills them.
By default, any newly created container starts using the new memory management scheme. To find out the amount of RAM and swap space set for a container, you can check the values of the
SWAPPAGES parameters in the container configuration file, for example:
# grep PHYSPAGES /etc/vz/conf/26bc47f6-353f-444b-bc35-b634a88dbbcc.conf PHYSPAGES="65536:65536" # grep SWAPPAGES /etc/vz/conf/26bc47f6-353f-444b-bc35-b634a88dbbcc.conf SWAPPAGES="65536"
In this example, the value of the
PHYSPAGES parameter for the container
MyCT is set to 65536. The
PHYSPAGES parameter displays the amount of RAM in 4-KB pages, so the total amount of RAM set for the container
MyCT equals to 256 MB. The value of the
SWAPPAGES parameter is also set to 256 MB.
To configure the amounts of RAM and swap space for the container
MyCT, use the
--swappages options of the
prlctl set command. For example, you can execute the following command to set the amount of RAM and SWAP in the container
MyCT to 1 GB and 512 MB, respectively:
# prlctl set MyCT --memsize 1G --swappages 512M
3.6.2. Configuring Container Memory Guarantees¶
A memory guarantee is a percentage of container’s RAM that it is guaranteed to have.
The total memory guaranteed to all running virtual environments on the host must not exceed host’s physical RAM size. If starting a virtual environment with a memory guarantee would increase the total memory guarantee on the host beyond host’s physical RAM size, the virtual environment will not start. If setting a memory guarantee for a running virtual environment would increase the total memory guarantee on the host beyond host’s physical RAM size, the memory guarantee will not be set.
For containers, the memory guarantee value is set to 0% by default. To change the default value, use the
prlctl set --memguarantee command. For example:
# prlctl set MyCT --memguarantee 80
To revert to the default setting, run
# prlctl set MyCT --memguarantee auto
3.6.3. Configuring Container Memory Allocation Limit¶
When an application starts in a container, it allocates a certain amount of memory for its needs. Usually, the allocated memory is much more than the application actually requires for its execution. This may lead to a situation when you cannot run an application in the container even if it has enough free memory. To deal with such situations, the VSwap memory management scheme introduces the new
vm_overcommit option. Using it, you can configure the amount of memory applications in a container may allocate, irrespective of the amount of RAM and swap space assigned to the container.
The amount of memory that can be allocated by applications of a container is the sum of RAM and swap space set for this container multiplied by a memory overcommit factor. In the default (basic) container configuration file, this factor is set to 1.5. For example, if a container is based on the default configuration file and assigned 1 GB of RAM and 512 MB of swap, the memory allocation limit for the container will be 2304 MB. You can configure this limit and set it, for example, to 3 GB by running this command:
# vzctl set MyCT --vm_overcommit 2 --save
This command uses the factor of 2 to increase the memory allocation limit to 3 GB:
(1 GB of RAM + 512 MB of swap) * 2 = 3 GB
Now applications in the container
MyCT can allocate up to 3 GB of memory, if necessary.
3.6.4. Configuring Container OOM Killer Behavior¶
The OOM killer selects one or more container processes to end based on the badness score reflected in
/proc/<PID>/oom_score. The badness score is calculated from process memory, total memory, and badness score adjustment, and then clipped to the range from 0 to 1000. Each point of the badness score stands for one thousandth of container memory. The process to be killed is the one with the highest resulting badness score.
The OOM killer can be configured by means of the standard systemd parameter
OOMScoreAdjust that adjusts badness score for a process, modifying its
/proc/<PID>/oom_score_adj value. The parameter accepts integers between -1000 (processes of this unit will not be killed) and 1000 (processes of this unit will very likely be killed under memory pressure). As with the badness score itself, each adjustment point stands for 1/1000 of total container memory. In an out-of-memory situation, the adjustment will guarantee that the process will be allowed to occupy at least
<oom_score_adj> thousandths of container memory while there are other processes with higher badness running in the container.
To adjust the badness score of service’s processes, add the
OOMScoreAdjust parameter to its configuration file. For example:
[Service] ... OOMScoreAdjust=500 ...
To apply the changes if the service is running, first reload systemd configuration with
systemctl daemon-reload, then restart the service itself with
systemctl restart <service>.
3.6.5. Tuning VSwap¶
The VSwap management scheme can be extended by using UBC parameters. For example, you can set the
numproc parameter to configure the maximal number of threads a container may create or the
numfile parameter to specify the number of files that may be opened by all processes in the container.