Meilleures pratiques pour régler le comportement de swappiness et du cache mémoire sous Linux

Linux utilise la RAM disponible. Cela surprend les gens la première fois qu'ils voient un serveur avec très peu de mémoire « libre » dans free -h. La majeure partie de cette mémoire peut être du cache de pages, des dentries et du cache d'inodes, et non une fuite. La partie difficile est de savoir quand le noyau utilise bien la RAM et quand la récupération de mémoire commence à nuire à vos applications.

Deux paramètres sysctl reviennent souvent lors du réglage de la mémoire Linux : vm.swappiness et vm.vfs_cache_pressure. Ils sont utiles, mais ce ne sont pas des interrupteurs de performance magiques. Une mauvaise valeur peut masquer le vrai problème ou déplacer la douleur d'une charge de travail à une autre.

Comprendre les paramètres de gestion de la mémoire Linux

Linux utilise des heuristiques pour décider quelles pages mémoire récupérer lorsque le système a besoin de plus de RAM libre. Les deux principaux domaines contrôlés par les paramètres du noyau sont l'échange (déplacement des pages mémoire inactives vers le disque) et la mise en cache (conservation des métadonnées et des données du système de fichiers dans la RAM).

1. `vm.swappiness`

vm.swappiness dicte la tendance du noyau à déplacer les processus de la mémoire physique vers l'espace d'échange sur le disque. C'est une valeur comprise entre 0 et 100.

Valeur élevée (par exemple, 60, une valeur par défaut courante) : Le noyau est plus enclin à récupérer la mémoire anonyme et à utiliser l'échange dans le cadre de la gestion normale de la mémoire. Cela peut préserver le cache de pages, mais peut également nuire aux services sensibles à la latence si des pages actives sont expulsées.
Valeur faible (par exemple, 10 ou moins) : Le noyau préfère récupérer la mémoire du cache de pages avant de commencer à échanger les processus. Cela maintient les applications en cours d'exécution plus longtemps dans la RAM, améliorant la réactivité mais réduisant potentiellement les performances d'E/S disque si le système doit constamment supprimer les pages du cache.
Valeur de 0 : Le noyau évite autant que possible l'échange, mais cela ne désactive pas l'échange. Si vous devez désactiver l'échange, utilisez swapoff et comprenez d'abord le risque de manque de mémoire.

Application pratique de `vm.swappiness`

Le réglage optimal dépend fortement de la charge de travail :

Type de charge de travail	Plage de `swappiness` recommandée	Justification
Serveurs de bases de données, Calcul haute performance (HPC)	1 - 10	Souvent un bon point de départ lorsque la latence d'échange est pire que la suppression du cache. Validez avec des métriques de charge de travail réelles.
Serveurs à usage général, Ordinateurs de bureau	30 - 60	Généralement raisonnable sauf si vous avez des preuves que le comportement d'échange vous nuit.
Systèmes de fichiers ou à forte intensité de cache	60 ou plus dans certains cas	Peut préserver le cache de pages, mais n'a de sens que si un échange occasionnel est acceptable pour la charge de travail.

Comment vérifier la valeur actuelle :

cat /proc/sys/vm/swappiness

Comment modifier la valeur temporairement (jusqu'au redémarrage) :

Pour définir swappiness à 10 :

sudo sysctl vm.swappiness=10

Comment modifier la valeur de manière permanente :

Modifiez le fichier /etc/sysctl.conf et ajoutez ou modifiez la ligne :

# /etc/sysctl.conf
vm.swappiness = 10

Après avoir enregistré, appliquez les modifications sans redémarrer en utilisant :

sudo sysctl -p

Pour les bases de données à forte intensité mémoire, 1 à 10 est un point de départ courant. Ne le traitez pas comme une règle. Une base de données qui possède déjà son propre cache de tampons, comme PostgreSQL ou MySQL/InnoDB, bénéficie généralement de l'évitement de l'échange. Un serveur de fichiers peut préférer un cache de pages plus grand. Une petite machine virtuelle avec trop peu de RAM souffrira quel que soit le nombre que vous choisissez.

2. `vfs_cache_pressure`

vfs_cache_pressure contrôle l'agressivité avec laquelle le noyau récupère la mémoire utilisée pour les métadonnées des répertoires et des inodes (le cache VFS).

Cette valeur va de 0 à 1000.
La valeur par défaut est généralement 100.

À une valeur de 100, le noyau équilibre la récupération de la mémoire du cache VFS par rapport à la récupération de la mémoire utilisée par le cache de pages (données disque). Une valeur de 100 signifie que lorsqu'il y a une pression mémoire, le noyau essaie de récupérer 1 partie de la mémoire du cache d'inodes/dentries pour chaque 1 partie de la mémoire du cache de pages.

Ajustement de `vfs_cache_pressure`

Augmentation de la valeur (par exemple, > 100) : Rend le noyau plus agressif dans la récupération de la mémoire du cache VFS. Cela libère de la RAM plus rapidement mais peut entraîner des recherches ultérieures plus lentes dans le système de fichiers, car les métadonnées doivent être lues à nouveau depuis le disque.
Diminution de la valeur (par exemple, < 100) : Rend le noyau plus conservateur dans la récupération du cache VFS. Cela conserve les informations sur les répertoires et les inodes en mémoire plus longtemps, accélérant les opérations répétées du système de fichiers.

Quand diminuer vfs_cache_pressure :

Si votre système accède fréquemment aux mêmes structures de répertoires volumineuses (courant dans les applications complexes, l'orchestration de conteneurs ou certaines configurations réseau), définir cette valeur plus basse (par exemple, 50) peut améliorer les performances en gardant les métadonnées facilement disponibles dans la RAM.

Quand augmenter vfs_cache_pressure :

Si votre système souffre d'une pression mémoire générale et que vous souhaitez que le noyau récupère toute mémoire inutilisée rapidement, vous pouvez augmenter cette valeur, bien que cela soit moins courant que de la diminuer.

Comment vérifier la valeur actuelle :

cat /proc/sys/vm/vfs_cache_pressure

Comment modifier la valeur de manière permanente :

Modifiez /etc/sysctl.conf :

# /etc/sysctl.conf
vfs_cache_pressure = 50

Appliquez les modifications avec sudo sysctl -p.

Avertissement : Des valeurs très basses de vfs_cache_pressure peuvent amener le noyau à conserver le cache des répertoires et des inodes plus longtemps que prévu. Cela peut aider les charges de travail à forte intensité de métadonnées, mais peut également aggraver la pression mémoire pour les applications. Évitez les valeurs extrêmes sauf si vous avez mesuré l'effet.

Scénarios de réglage complets

Choisir la bonne combinaison de ces paramètres optimise le compromis entre la stabilité des applications et la mise en cache du système de fichiers.

Scénario 1 : Serveur de base de données (Priorité mémoire)

Objectif : Maximiser la résidence mémoire des applications ; minimiser l'échange à tout prix.

vm.swappiness = 5
vfs_cache_pressure = 50 (Conserver les données de répertoire mises en cache dans une certaine mesure, mais privilégier la mémoire des applications par rapport aux métadonnées VFS si la RAM devient limitée).

Avant de changer quoi que ce soit, vérifiez si la base de données échange réellement :

free -h
vmstat 1
grep -E 'pswpin|pswpout' /proc/vmstat

Si les compteurs d'échange entrant et sortant augmentent pendant les pics de latence des requêtes, abaisser le swappiness peut aider. Si l'échange est inutilisé et que la base de données est lente, le swappiness n'est pas votre problème. Examinez plutôt les plans de requêtes, le taux de succès du tampon, les points de contrôle, la latence du disque et la pression de connexion.

Scénario 2 : Serveur à E/S disque élevée (Priorité à la mise en cache)

Objectif : Maximiser les performances du disque en conservant les données des fichiers fréquemment consultés dans le cache de pages.

vm.swappiness = 80 (Permet à l'échange de se produire plus tôt pour libérer de la RAM pour l'expansion du cache disque).
vfs_cache_pressure = 100 (Équilibre standard entre le cache d'inodes et le cache de pages).

C'est le scénario où les gens font le plus souvent un sur-réglage. Si le serveur lit principalement les mêmes fichiers de manière répétée, le cache de pages est important. Mais si le système commence à échanger des processus de travail actifs pour préserver le cache, les utilisateurs peuvent voir une latence plus mauvaise même si le cache du système de fichiers semble sain. Surveillez le temps de réponse des applications, pas seulement la taille du cache.

Scénario 3 : Hôte de virtualisation ou système à usage général

Objectif : Performances stables sur plusieurs charges de travail.

vm.swappiness = 30 (Un réglage modéré qui favorise le maintien des VM/processus actifs dans la RAM un peu plus longtemps que la valeur par défaut de 60, mais permet toujours un échange contrôlé).
vfs_cache_pressure = 100 (La valeur par défaut est souvent suffisante).

Les hôtes de virtualisation nécessitent une prudence supplémentaire car le comportement mémoire des invités peut induire en erreur le réglage au niveau de l'hôte. Le ballonnement, la sur-allocation et l'échange des invités peuvent tous interagir. Un hôte qui échange fortement la mémoire des invités peut créer une latence douloureuse à l'intérieur des VM même lorsque chaque invité pense que sa propre charge de travail est normale.

Un workflow de réglage plus sûr

Ne commencez pas par modifier /etc/sysctl.conf. Commencez par prouver que le réglage est pertinent.

Capturez une référence pendant la charge normale :

free -h
vmstat 1 10
cat /proc/sys/vm/swappiness
cat /proc/sys/vm/vfs_cache_pressure

Capturez les mêmes données pendant la période lente. Ajoutez la mémoire au niveau des processus :
```
ps -eo pid,comm,rss,vsz,%mem --sort=-rss | head -20
```
Modifiez une valeur temporairement :
```
sudo sysctl vm.swappiness=10
```
Exécutez la charge de travail suffisamment longtemps pour observer le comportement. Recherchez une activité d'échange plus faible, une meilleure latence des applications et aucun nouveau ralentissement du système de fichiers.
Rendez la valeur persistante uniquement après qu'elle ait survécu à une fenêtre de test réaliste.

Sur les systèmes qui utilisent /etc/sysctl.d/, un petit fichier dédié est souvent plus propre que d'ajouter à /etc/sysctl.conf :

sudo tee /etc/sysctl.d/90-memory-tuning.conf >/dev/null <<'EOF'
vm.swappiness = 10
vm.vfs_cache_pressure = 100
EOF

sudo sysctl --system

Si votre système de gestion de configuration possède les paramètres sysctl, placez-y plutôt le changement. Les modifications manuelles de sysctl sur un seul serveur sont faciles à oublier et difficiles à reproduire.

Lire `free -h` sans paniquer

Une sortie typique de free -h peut montrer un petit nombre sous free et un grand nombre sous buff/cache. C'est normal. Linux conserve les données des fichiers récemment utilisés en mémoire car la RAM inutilisée n'aide personne.

Concentrez-vous sur available, l'utilisation de l'échange et si une activité d'échange se produit actuellement. Un serveur peut avoir de l'échange alloué à partir d'un pic de mémoire passé mais aucun churn d'échange actuel. C'est moins urgent qu'un serveur qui échange constamment.

Utilisez :

vmstat 1

Si si et so restent proches de zéro sous charge normale, l'échange n'entraîne pas activement de latence à ce moment-là. S'ils restent non nuls tandis que les applications calent, la pression mémoire est un suspect sérieux.

Quand ne pas régler ces paramètres

Il existe plusieurs cas où la modification du swappiness ou de la pression du cache est la mauvaise première solution.

Si le serveur n'a pas d'échange configuré, vm.swappiness a peu d'effet pratique. Vous pouvez toujours le régler pour la cohérence des politiques, mais cela ne résoudra pas la pression mémoire par lui-même.

Si l'échange n'existe que comme une petite partition d'urgence, le réglage a également une marge de manœuvre limitée. Le noyau peut choisir quand utiliser l'échange, mais il ne peut pas transformer quelques centaines de mégaoctets d'espace d'urgence en un véritable niveau de mémoire. Dans cette configuration, concentrez-vous sur le risque de OOM et les limites de service.

Si un processus a une véritable fuite mémoire, abaisser le swappiness retarde la douleur. La fuite continuera de croître. Redémarrer le service peut restaurer temporairement la capacité, mais la solution durable est au niveau de l'application : corrigez la fuite, limitez la mémoire, réduisez la concurrence ou modifiez la charge de travail.

Si le disque est lent en raison d'un disque défaillant, d'une limitation du stockage ou d'un volume cloud saturé, le réglage de la mémoire peut réduire certaines lectures mais ne corrigera pas le défaut de stockage. Vérifiez iostat, les journaux du noyau, les métriques du volume cloud et la santé SMART/NVMe.

Si l'ensemble de travail est plus grand que la RAM, il n'y a pas de valeur sysctl parfaite. Vous avez besoin de plus de mémoire, de moins de concurrence, de caches plus petits, d'une disposition de données différente ou d'une répartition de la charge de travail.

Notes sur les conteneurs et Kubernetes

Le réglage de la mémoire devient plus délicat dans les conteneurs. Un conteneur peut atteindre sa limite de mémoire cgroup même si l'hôte a de la RAM libre. Le réglage du swappiness de l'hôte compte toujours, mais le symptôme immédiat peut être un kill OOM à l'intérieur d'un pod ou d'un conteneur.

Vérifiez les signaux du cgroup et de l'orchestrateur :

dmesg -T | grep -i 'killed process'
docker stats
kubectl describe pod <nom-du-pod>

Pour Kubernetes, la modification des sysctls au niveau du nœud doit faire partie de la configuration du pool de nœuds, et non d'une session shell ponctuelle. N'oubliez pas non plus que certains sysctls sont dans un espace de noms et d'autres sont au niveau du nœud. vm.swappiness et vm.vfs_cache_pressure sont des paramètres au niveau de l'hôte sur les systèmes Linux typiques, donc les modifier affecte chaque charge de travail sur ce nœud.

Surveillance et validation

Après avoir appliqué les modifications, une surveillance continue est cruciale pour valider l'impact. Utilisez des outils comme free, vmstat et des tableaux de bord de surveillance des performances système.

Utilisation de vmstat :

Surveillez les colonnes si (échange entrant) et so (échange sortant). Un système sain avec un swappiness faible devrait montrer des valeurs faibles ou nulles pour si et so sous charge normale.

vmstat 5 10

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\ r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 123456 102400 5123456    0    0     0     5   40   70  1  1 98  0  0

Si les valeurs so restent élevées après avoir réduit le swappiness, la charge de travail a probablement besoin de plus de mémoire utilisable ou d'une demande mémoire plus faible. Plus de RAM est une réponse, mais pas la seule. Vous pouvez également réduire le nombre de workers, réduire les caches d'application, régler la mémoire de la base de données, corriger les fuites ou répartir les services sur plusieurs hôtes.

Traitez vm.swappiness et vm.vfs_cache_pressure comme des préférences de charge de travail, et non comme des mises à niveau universelles. Le chemin pratique est ennuyeux mais fiable : mesurez le comportement actuel de l'échange et de la récupération, modifiez un paramètre, testez sous charge réelle et ne conservez la modification que si le comportement de l'application s'améliore.