VZ 4.7 – problemas de memoria – caso práctico

Tenemos un VPS que nos da el siguiente error

[cc] Fatal resource shortage: privvmpages, UB 101.
[/cc]
Entramos en vps

[cc] vzctl enter 101
[/cc]

Comprobamos memoria

[cc] free -m
total used free shared buffers cached
Mem: 512 469 42 0 0 53
-/+ buffers/cache: 416 95
Swap: 0 0 0
[/cc]

Vemos que, está máquina tiene configurado 512MB. Nosotros sabemos que, venimos de un modo SLM en el que, 512MB era el softlimit mientras que el hardlimit es de 756MB. Problemas, en 4.7 no está el modo SLM y se ha sustituido por VSwap.

En el momento en que entramos, no tuvimos problemas pero otras veces vemos “Cannot Allocate Memory”. Estamos en un caso complejo de:

– VPS con problemas de recursos, ha sobrepasado el tiempo de gracia y se reduce su RAM a softlimit
– VPS con configuración 4.6 en VZ 4.7

Al mover nuestros VPS a 4.7, automáticamente todos empiezan a usar el nuevo esquema de RAM. En el caso de SLM es asi:

– el total de RAM lo marca slmmemorylimit
– el total de swap es 0
– el límite de memoria a alojar es el valor de slmmemorylimit por 1.5.

El nuevo esquema tiene este comportamiento:

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, 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.

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.

En todo caso, estamos ante un problema de recursos, pero vamos a aplicar ya la nueva configuración.

[cc] cd /vz/private/VEID/
cp ve.conf ve.conf.bak
[/cc]

editamos ve.conf y eliminamos cualquier mención de SLM

[cc] vctl restart VEID
[/cc]

El vps no se va a levantar pues, no tiene parámetros UBC o Vswap que aplicar. Es justo lo que queremos.

[cc] Resource parameter numproc is not set
Resource parameter numtcpsock is not set
Resource parameter numothersock is not set
Resource parameter vmguarpages is not set
Resource parameter kmemsize is not set
Resource parameter tcpsndbuf is not set
Resource parameter tcprcvbuf is not set
Resource parameter othersockbuf is not set
Resource parameter dgramrcvbuf is not set
Resource parameter oomguarpages is not set
Resource parameter lockedpages is not set
Resource parameter shmpages is not set
Resource parameter privvmpages is not set
Resource parameter numfile is not set
Resource parameter numflock is not set
Resource parameter numpty is not set
Resource parameter numsiginfo is not set
Resource parameter dcachesize is not set
Resource parameter physpages is not set
Resource parameter numiptent is not set
Not enough parameters to start the Container
Container is unmounted
Failed to start the Container
[/cc]

Ahora configuramos los parámetros teniendo en cuenta, las necesidades del VPS

[cc] vzctl set 101 –save –ram 1G –swap 512M
[/cc]

Rebotamos el VPS y miramos ahora la nueva configuración

[cc] total used free shared buffers cached
Mem: 1024 236 787 0 0 38
-/+ buffers/cache: 198 825
Swap: 512 0 512
[/cc]

Si abrimos el fichero veremos los dos parámetros añadidos

[cc] PHYSPAGES=”262144:262144″
SWAPPAGES=”131072:131072″
[/cc]

PHYSPAGES muestra el valor total de RAM en páginas de 4KB, así como el valor de SWAPPAGES. Aún así desde la documentación oficial se nos “insta” a poder tunear el VPS a un nivel más granular con parámetros UBC.

Otro parámetro a tener en cuenta es overcommit. Lo que nos genera la duda, al menos a mí, sobre el nuevo esquema de memoria. La duda es sobre si se refiere exclusivamente a una app (application) de un template VZ o aplicaciones en general :-/ La teoría dice:

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 RAM.

To deal with such situations, the VSwap memory management scheme introduces a new parameter—VM_Overcommit. Using this parameter, 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, the memory allocation limit for the Container will be 2304 MB.

Bueno, ha sido una primera aproximación a este nuevo esquema de memoria.