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:

  • RAM determines the total size of RAM that can be used by the processes of a container.

  • swap determines 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:

  1. You set for a container a certain amount of RAM and swap space that can be used by the processes running in the container.

  2. When the container exceeds the RAM limit set for it, swapping starts. The process is similar to that on a standalone computer. Container’s swap space resides in a swap file on the physical node. When the swap-out for a container starts, the container starts to consume physical swap. If a swap file is not configured on the node, the SWAPPAGES parameter is ignored.

  3. Once the container exceeds its swap limit, the system invokes the OOM Killer for this container.

  4. 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 PHYSPAGES and SWAPPAGES parameters in the container configuration file, for example:

# grep PHYSPAGES /etc/vz/conf/26bc47f6-353f-444b-bc35-b634a88dbbcc.conf
# grep SWAPPAGES /etc/vz/conf/26bc47f6-353f-444b-bc35-b634a88dbbcc.conf

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 --memsize and --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:


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.