Search Engine: Elastic

Article ID: 128263, created on Feb 7, 2016, last review on Jul 14, 2018

  • Applies to:
  • Operations Automation 6.0
  • Operations Automation 5.5


After switching VPS memory mode from SLM to 'Combined SLM + UBC mode' and setting swappages parameter, container misbehaves and shows memory-related errors, e.g.:

[root@vz ~]# vzctl enter 111
Unable to fork: Cannot allocate memory

Switching back to SLM mode makes the container stable again.


'Combined SLM + UBC mode' utilizes the whole set of UBC parameters, so it is needed to configure each parameter appropriately.

In case vSwap mode is used on the Virtuozzo server (Virtuozzo containers 4.7 and Virtuozzo 6.0), it is required to set physpages (RAM in 4KB pages), swappages (SWAP in 4KB pages) and privvmpages (memory overcommit in 4KB pages) parameters.

SLM mode, in turn, uses a single parameter SLMMEMORYLIMIT, which eases the memory management of such containers. With vSwap mode, the limit is converted automatically to RAM (physpages) and memory overcommit parameter is set to 1.5 * RAM (privvmpages) by default, unless other limits are defined for the VPS in its configuration file.


When switching to 'Combined SLM + UBC mode', make sure the following parameters are configured properly:

  • physpages - should be set in accordance with memory limit in 4 KB pages, e.g. if RAM limit is 1 GB, physpages should be set to 262144
  • swappages - can be set according to the demand, in 4 KB pages as well
  • privvmpages - to emulate the default Linux behavior, it should be set to 1.5 * (RAM + SWAP)

All other UBC parameters can be left without changes, OA applies automatically calculated values on them.

Additional information

Check the following articles for additional information on vSwap:

Is it possible to manage 'vswap' parameter for VPS in POA?
How vSwap memory management scheme configures UBC parameters in POA?
Memory limits in Virtuozzo Containers for Linux

5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 e12cea1d47a3125d335d68e6d4e15e07 956c448bddc7e1f3585373687602379f 6f1456866eed87488c0f02b298a741c0 5b048d9bddf8048a00aba7e0bdadef37 2554725ed606193dd9bbce21365bed4e

Email subscription for changes to this article
Save as PDF