Limiter la mémoire

Limiter la mémoire jpp dim 05/01/2020 - 23:05

Limiter la mémoire utilisable par une instance LXC.
Note : la machine physique de test dispose de 16Go de RAM et de 8Go de Swap, elle fonctionne avec un kernel très récent (à l'époque) : 5.6.7, quasiment le dernier sorti à ce jour.
Sans aucune limitation l'instance LXC dispose de l'intégralité de la mémoire de la machine physique, "free mem" montre :
total used free shared buff/cache available
Mem: 16363688 17616 16281500 8184 64572 16346072
Swap: 8811516 0 8811516
On voit bien 16Go de mémoire et un swap de 8Go.
Pour limiter la mémoire utilisable par notre container on met en place les paramètres suivants :

lxc.cgroup.memory.limit_in_bytes = 128M
lxc.cgroup.memory.memsw.limit_in_bytes = 192M
Après redémarrage du conteneur "free mem" donne alors :
total used free shared buff/cache available
Mem: 131072 12332 105408 8184 13332 118740
Swap: 196608 8 196600
Ce qui correspond bien aux paramètres fixés, la commande "lxc-info" est plus bavarde et donne plus de renseignements :
lxc-info debian-d
Name: debian-d
State: RUNNING
PID: 8280
IP: 192.168.3.12
Memory use: 36.44 MiB
KMem use: 7.50 MiB
Link: veth9SRIEJ
TX bytes: 7.89 KiB
RX bytes: 12.70 KiB
Total bytes: 20.59 KiB
Au passage une petite singularité : la variable "$HOME" de root n'est pas initialisée dans le conteneur mais se trouve ici égale à "/home/testlxc" (HOME de l'utilisateur qui a lancé l'instance). J'ai du installer dans .profile "export HOME=/root" et il faut en plus utiliser un "switch" lors du lancement de lxc-attach en ajoutant :
--clear-env. Comme par miracle on se retrouve alors avec une variable HOME correcte.

Ajuster la mémoire

Ajuster la mémoire drupadmin mer 10/01/2024 - 23:13

Si l'on veut s'intéresser aux limitations concernant le CPU (en % et en nombre de CPU) il va falloir donner à notre utilisateur quelques droits supplémentaires sur les CGROUPS.
En effet, par défaut (sur une Debian Buster), seuls les droits sur "freezer" et "memory" sont attribués aux utilisateurs il faut donc ajouter les droits sur "cpu","cpuset" et "cpuacct" pour pouvoir "jouer" avec les paramètres "cpu".
Il faut corriger un fichier de PAM qui permet d'attribuer ces droits : /etc/pam.d/common-session :
Ligne originale :
session   optional   pam_cgfs.so -c freezer,memory,name=systemd
Ligne corrigée :
session   optional   pam_cgfs.so -c freezer,memory,cpu,cpuset,cpuacct,blkio,name=systemd
Après reconnection de notre utilisateur "testlxc", vérifier quels cgroups sont "autorisés" avec :
cat /proc/self/cgroup | grep testlxc
10:cpuset:/user/testlxc/0
9:blkio:/user/testlxc/0
8:freezer:/user/testlxc/0
4:cpu,cpuacct:/user/testlxc/0
Le "grep testlxc" est à adapter en fonction de votre utilisateur et cela évite des lignes inutiles ...
Note j'ai ajouté "blkio" qui sera utilisable plus tard ...
Autre "bizarrerie" découverte lors de ce test :
La commande "df" renvoie la taille du disque physique porteur du "rootfs" et non la taille du "rootfs" lui même, on n'est pas dans une machine virtuelle !
J'ai installé Apache/Php/Opcache dans ce conteneur et j'ai quelque peu bataillé avec la mémoire partagée : il faut mettre de "bons" paramètres (kernel.shm...) :

Dans notre conteneur

local.conf:kernel.shmmax = 34359738368
local.conf:kernel.shmall = 131072
local.conf:kernel.shmmni = 65536

. Mais aussi dans la machine physique

local.conf:kernel.shmmax = 34359738368
local.conf:kernel.shmall = 536870912
local.conf:kernel.shmmni = 65536
afin de permettre à Opcache d'initialiser la mémoire nécessaire.
Paramètres ajustés dans le fichier "config":
# limiter mémoire
lxc.cgroup.memory.limit_in_bytes = 384M
lxc.cgroup.memory.memsw.limit_in_bytes = 640M

Les valeurs données ci-dessus sont indicatives .. mais elles ont fonctionné pour moi et Apache a pu démarrer avec Opcache.
Après ces quelques ajustements le site est accessible normalement de l'extérieur ... et les performances sont aussi bonnes que sur la machine physique.