Proxmox/LXC gestion SWAP

Tech
,
1

Bonjour à tous,

Récemment, suite à la lecture de ceci : https://www.le5emeaxe.fr/proxmoxetswap-2/ et au constat que le notre serveur proxmox du Retzien SWAPai tôt… j’ai changé le vm.swappiness du serveur à 10 (avant à 60). Chez lui ça semble avoir eu un effet :

root@srvprox1:~# free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi       7,6Gi       398Mi       886Mi       7,2Gi       6,3Gi
Swap:         8,0Gi       1,5Gi       6,5Gi

Mais pas tant dans les container :

root@srvcloud:~# free -h
              total        used        free      shared  buff/cache   available
Mem:          7,8Gi       1,0Gi       3,8Gi       249Mi       3,0Gi       6,8Gi
Swap:         7,8Gi       565Mi       7,3Gi

swap-day

Le paramètre dans le container est pourtant aussi à 10 (récupéré du serveur ?) :

root@srvcloud:~# sysctl vm.swappiness
vm.swappiness = 10

Est-ce que la gestion de la SWAP se tripote à un autre endroit sur des containers LXC / proxmox ? Vous faites comment vous ? (ceux qui, comme moi flippe de ne pas mettre de SWAP… parce que je sais que certain n’en utilise pas : https://forum.chatons.org/t/swap-pas-swap-telle-est-la-question/1555 )

Merci pour vos lumières,
David

2

Salut David,

Je n’utilise pas Proxmox donc je ne suis pas sur que ma réponse puisse t’aider, par contre j’utilise LXC également.

Je fais partie des personnes qui préfère sécuriser et avoir un swap plutôt que de risquer d’avoir un serveur qui tombe.

[hors sujet] ON

J’utilise également zram-tools qui permet d’optimiser l’espace en mémoire vive et eviter que le serveur ne swap trop

[hors sujet] OFF

A la base la mémoire vive et le swap du serveur sont partagés sur les conteneurs.
Tu peux paramétrer la quantité de mémoire et swap via les cgroups, c’est certainement ce que fait Proxmox je pense

Dans certains cas, selon la la distribution que tu utilises, il faut ajouter cette option au grub swapaccount=1 (mais encore une fois c’est hors usage de proxmox).

Après, comme souvent, les graphs que tu nous montres sont un snapshot instantané, peut être que à un moment donnée, la mémoire vive de ton container a été consommé et il a eu besoin de swappé

Ce qui est intéressant est aussi de voir ce qui a été swappé pour comprendre l’usage, exemple de commande sur Debian

for file in /proc/*/status ; do awk '/Tgid|VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | grep kB  | sort -k 3 -n

Je ne t’apporte pas directement les réponses que tu attends mais peut être des pistes.

@+

3

Merci @ManchotManosquin pour ces début de pistes.

Pour m’en assurer je peux voir ça quelque part ? Je trouve pas foule de doc pertinente sur le sujet…

Ta petite commande me rends dubitative, je ne sais pas quoi en pensé, il y a « un peu de tout » mais ça chang quoi de savoir qui part dans la SWAP ? C’est pas le système qui décide où ça part ? En l’occurence ce qui est éttrange c’est la tendance à « déjà swapper » avant d’utiliser la RAM

Sur le serveur Nextcloud c’est criant :

root@nextcloud:~# for file in /proc/*/status ; do awk '/Tgid|VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | grep kB  | sort -k 3 -n
awk 433 0 kB
awk 434 0 kB
bash 392 0 kB
bash 397 0 kB
bash 398 0 kB
pickup 32636 0 kB
sort 399 0 kB
sshd 373 0 kB
systemd 376 0 kB
agetty 141 48 kB
agetty 139 56 kB
agetty 140 56 kB
cron 70 172 kB
dbus-daemon 72 332 kB
sshd 265 704 kB
master 378 720 kB
qmgr 380 724 kB
systemd-logind 74 752 kB
(sd-pam) 377 764 kB
rsyslogd 73 844 kB
systemd 1 912 kB
systemd-journal 1916 2648 kB
apache2 31846 3440 kB
apache2 31845 3532 kB
apache2 31844 3540 kB
apache2 31242 3544 kB
apache2 32135 3544 kB
apache2 369 3656 kB
apache2 32738 3676 kB
apache2 30207 4044 kB
apache2 30213 4096 kB
apache2 30205 4116 kB
apache2 16835 5976 kB
turnserver 16302 6640 kB
mysqld 12868 236292 kB
root@nextcloud:~# free -h
              total        used        free      shared  buff/cache   available
Mem:          4,0Gi       181Mi       3,7Gi        24Mi       133Mi       3,8Gi
Swap:         1,0Gi       330Mi       693Mi
4

Alors sous Debian, j’ai toutes les informations qui se trouve ici

/sys/fs/cgroup/memory/lxc/nom_de_ton_instance/

Et les fichiers qui contiennent les valeurs qui t’intéresse sont les suivants :

  • memory.memsw.usage_in_bytes

  • memory.memsw.max_usage_in_bytes

  • memory.memsw.limit_in_bytes : tu peux soit définir la valeur limite de swap dans ton container en modifiant la valeur dans ce fichier ou en utilisant la commande

    lxc-cgroup -n nom_de_ton_instance memory.memsw.limit_in_bytes 2G

Tu peux normalement aussi mettre des valeurs dans ton fichier config de ton instance.
Attention ! Point important les valeurs sont pour la mémoire + le swap pour memsw, donc au minumum ça doit etre équivalent à la taille de ta mémoire allouée.

Oui bien entendu c’est le système qui décide ce qui va dans le swap ou pas.
Mais par contre de savoir ce qui fait que tu as du swap est important car cela te permet de comprendre, d’analyser et d’essayer d’agir ensuite dessus.

On voit dans ton exemple qu’il y a 2 éléments qui ont swappé, ce qui est logique car c’est ce qui consomme le plus, apache2 et surtout ton server mysql.

Je pense qu’il serait intéressant de voir à quel moment ton serveur mysql utilise autant de mémoire, voir si il y a des optimisations que tu pourrais faire, jamais simple.

Après il faudrait voir la version de lxc installé, le kernel…

Bon courage

5

Merci c’est instructif ! Je viens de faire une tentative, une VM avec 8Go de RAM + 8Go de SWAP, par défaut :

root@srvprox1:~# cat /sys/fs/cgroup/memory/lxc/104/memory.memsw.limit_in_bytes 
16777216000

Dans le container (le container nextcloud cité au dessus) :

root@nextcloud:~# free -h
              total        used        free      shared  buff/cache   available
Mem:          7,8Gi       1,3Gi       3,9Gi       127Mi       2,6Gi       6,5Gi
Swap:         7,8Gi       929Mi       6,9Gi

Après application de la limit cgroup :

root@srvprox1:~# lxc-cgroup -n 104 memory.memsw.limit_in_bytes 8777216000
root@srvprox1:~# cat /sys/fs/cgroup/memory/lxc/104/memory.memsw.limit_in_bytes 
8777216000

Dans le container ça agit uniquement comme si j’avais juste alloué moins de SWAP via proxmox :

root@srvcloud:~# free -h
              total        used        free      shared  buff/cache   available
Mem:          7,8Gi       1,3Gi       3,8Gi       151Mi       2,7Gi       6,5Gi
Swap:         370Mi       370Mi          0B

:expressionless:

LXC de debian Buster / Proxmox 6 : https://packages.debian.org/buster/admin/lxc 3.1.0

root@srvprox1:~# uname -a
Linux srvprox1 5.4.65-1-pve #1 SMP PVE 5.4.65-1 (Mon, 21 Sep 2020 15:40:22 +0200) x86_64 GNU/Linux
root@srvprox1:~# lxcfs --version
4.0.3

Il y aurait certainement des optimisations de config à faire… Mais je comprends pas pourquoi une VM avec autant de RAM « Unused » swap, pour moi il devrait swapper plus tard, quand ça commence a arriver au bout. je vais finir par basculer dans le groupe « pas de swap » si ça continue…

J’ai essayé de faire des corrélations avec des tâches planifier ou autres mai si n’y a rien de criant, c’est « toute la journée »

swap-day

memory-day

Plus j’avance / j’ai l’impression de maîtriser un outil (ici linux) moins j’ai l’impression de maîtriser :-o

6

Intéressant comme cas et analyse, je reconnais que j’ai jamais poussé l’analyse complètement.

Pour la commande pour modifier la valeur effectivement, il y a celle qui permet de réduire uniquement la mémoire et celle la mémoire et le swap, celle que je t’ai donnée, donc forcément ça agit essentiellement la dessus.

Petite aparté, on peut voir qu’il est dans tous les cas recommandé d’avoir à minima 4 Go de Swap sur des serveurs (un exemple parmi d’autre https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-swapspace)

ça n’est pas lié à Linux mais plus à la gestion de la mémoire quelque soit le système, même le système d’échange de Windows n’est pas simple à analyser et paramétrer.

A moins de trouver un expert en la matière, on peut que s’appuyer sur nos analyses et essayer de comprendre en fonction des différentes données que nous avons.

Entre la partie mémoire, shared, cache et swap… il y a de la matière à analyser.
Surtout que comme tu l’as dit dans ta première analyse, il y a aussi le paramètre swapiness mais également le fait que selon si le besoin mémoire est contigu cela peut swapper au lieu d’utiliser la ram…

Ici la problématique est double entre le système de base et les instances lxc, même si l’on peut paramétrer des limites, est ce que le système swap parce que l’un des lxc consomme trop ou plutôt l’ensemble car malgré tout c’est des ressources partagées.

D’où le besoin d’analyse avec la commande que je t’ai donnée pour essayé de comprendre qui a pris quoi sur chaque instances et voir ensuite le delta sur le serveur et ses ressources.

7

En complément voici quelques articles intéressant sur le sujet du swap, du cache et de la mémoire qui sont par contre en anglais :

https://rudd-o.com/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that

https://chrisdown.name/2018/01/02/in-defence-of-swap.html

https://haydenjames.io/linux-performance-almost-always-add-swap-space/