Explication de la gestion de la mémoire sous Linux : swap, OOM killer et cgroups

Linux gère la mémoire différemment de la plupart des systèmes d'exploitation. Une utilisation élevée de la RAM n'est pas toujours un problème : le noyau utilise activement la mémoire libre pour la mise en cache afin d'accélérer les lectures sur le disque. Mais lorsque la pression sur la mémoire réelle s'intensifie, trois mécanismes entrent en action : le swap, l'OOM killer et les cgroups. Comprendre le fonctionnement de chacun d'entre eux et savoir les configurer fait la différence entre un serveur qui se dégrade progressivement sous la charge et un serveur qui plante sans avertissement.

Comment Linux gère les pages de mémoire

Chaque processus s'exécute dans son propre espace d'adressage virtuel, pouvant atteindre 128 To sur les systèmes 64 bits. Le noyau mappe ces adresses virtuelles à la mémoire vive physique via des tables de pages, le Translation Lookaside Buffer (TLB) mettant en cache les recherches récentes. Un accès TLB prend environ 1 nanoseconde ; un échec coûte entre 20 et 100 nanosecondes, ce qui s'accumule dans les charges de travail gourmandes en mémoire comme les bases de données.

La mémoire physique est divisée en pages de 4 Ko, et le noyau les classe en deux catégories :

• Pages adossées à des fichiers — liées à des fichiers sur le disque. Le noyau peut supprimer celles qui sont propres ou vider celles qui sont sales sans avoir besoin de la mémoire d'échange.
• Pages anonymes — mémoire de la pile et du tas sans fichier de sauvegarde. Celles-ci doivent être écrites dans l'espace d'échange avant que le noyau puisse les libérer.

Sur les serveurs à forte demande de mémoire, une proportion importante de pages anonymes signifie que l'espace d'échange est sollicité très tôt. Surveillez le si (swap in) et so (sortie de la mémoire d'échange) dans vmstat 1 : des valeurs non nulles persistantes constituent le premier signe que le système est sous pression.

Pour la surveillance, utilisez l'outil adapté à la tâche :

Une erreur courante : surveiller la free colonne free -h et céder à la panique. C'est la available colonne est ce qui importe. Elle inclut la mémoire que le noyau peut récupérer à partir du cache à la demande. Un serveur affichant seulement 512 Mo de mémoire libre mais 5 Go de mémoire disponible n’est pas en difficulté.

Lorsque la mémoire descend en dessous d'un seuil, le kswapd démarre la récupération de pages en arrière-plan. Si cela ne suffit pas, le noyau passe en mode de récupération directe, bloquant les processus jusqu’à ce que les pages soient libérées. C’est de là que proviennent les pics de latence. Configurez une alerte lorsque MemAvailable tombe en dessous de 10 à 15 % de la RAM totale afin d’avoir le temps de réagir.

Configuration de la mémoire swap

L'espace d'échange est une zone du disque — une partition ou un fichier — où le noyau déplace les pages anonymes inactives lorsque la mémoire vive (RAM) est saturée. La différence de vitesse est significative : la RAM DDR4 a une latence d'environ 100 ns, tandis que les SSD NVMe sont autour de 100 000 ns et les SSD SATA plus proches de 500 000 ns. L'espace d'échange est une zone tampon de sécurité, pas de la RAM supplémentaire. Un serveur qui dépend constamment de l'espace d'échange a un problème de mémoire que davantage d'espace d'échange ne résoudra pas.

Utilisez un fichier swap plutôt qu'une partition. Il est plus facile à redimensionner et ne nécessite pas de repartitionnement.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Ajoutez le fichier /etc/fstab pour qu'il persiste après les redémarrages. L' chmod 600 étape est obligatoire : toute donnée paginée hors de la RAM est lisible depuis la zone d'échange, le fichier ne doit donc pas être accessible en lecture à tous.

Après avoir créé la zone d'échange, réglez vm.swappiness. La valeur par défaut de 60 est agressive. Pour la plupart des charges de travail d'hébergement, vous souhaitez que le noyau privilégie la RAM et n'utilise le fichier d'échange qu'en dernier recours :

Pour la taille de la zone d'échange : 1–2 Go suffisent pour un VPS de 2 Go gérant des pics de trafic occasionnels. Sur les systèmes disposant de 8 Go ou plus, une zone d'échange fixe de 2–4 Go est généralement suffisante. L'objectif est de fournir au noyau une soupape de décompression pour les pages froides, et non d'étendre la mémoire adressable totale.

Sur les serveurs à mémoire vive limitée mais dotés d'un processeur puissant, zram crée une zone de swap compressée en mémoire, évitant ainsi complètement les E/S disque. Cela vaut la peine d'être envisagé sur les hébergements VPS multi-locataires où le NVMe est partagé entre les locataires. Surveillez les conflits d'E/S si le swap réside sur le même périphérique que les fichiers de base de données — un swap intensif et des écritures disque à haut débit ne font pas bon ménage.

L'OOM killer

Lorsque le noyau épuise la RAM et l'espace d'échange et ne peut pas récupérer suffisamment de mémoire par d'autres moyens, l'OOM killer intervient. Il évalue les processus à l'aide de la oom_badness() fonction suivante :

points = (rss_anon + rss_file + rss_shmem + swapents + pgtables_pages) + (oom_score_adj × totalpages / 1000)

Le processus ayant le score le plus élevé est tué. La formule privilégie les gros consommateurs de mémoire, et le noyau évite de tuer plusieurs processus en succession rapide en vérifiant si un processus a déjà été terminé au cours des 5 dernières secondes.

Deux types d'événements OOM apparaissent dans les journaux :

• OOM global — le système tout entier est à court de RAM et d'espace d'échange. Les journaux sont préfixés par Out of memory:
• OOM Cgroup — un conteneur ou un service a atteint sa memory.max limite. Les journaux sont préfixés par Memory cgroup out of memory:

Pour consulter les événements OOM passés :

dmesg -T | grep -i "out of memory"
journalctl -k --grep="oom"

Prêtez attention au order champ dans les journaux OOM. Une valeur supérieure à 0 suggère une fragmentation de la mémoire plutôt qu'un épuisement total — le noyau n'a pas pu trouver suffisamment de pages contiguës même avec de la mémoire libre disponible.

Vous pouvez influencer les processus ciblés par l'OOM killer en ajustant /proc/<pid>/oom_score_adj. La plage va de -1000 (ne jamais tuer) à +1000 (tuer en premier). Pour les services gérés par systemd, définissez ce paramètre de manière permanente dans le fichier d'unité :

[Service]
OOMScoreAdjust=-1000

Paramètres sysctl supplémentaires pour régler le comportement OOM :

Pour une surveillance proactive, consultez /proc/pressure/memory (Pressure Stall Information, disponible depuis le noyau 4.20). Surveillez la some avg10 valeur : en dessous de 5 %, tout va bien ; si elle reste au-dessus de 20 %, un événement OOM est probable. Un allocstall compteur dans /proc/vmstat est un autre signe précurseur — il compte les blocages de récupération directe, qui précèdent souvent les arrêts OOM. Des outils comme systemd-oomd ou earlyoom peuvent intervenir en fonction des seuils PSI avant que le mécanisme OOM killer du noyau ne se déclenche.

Cgroups et limites de mémoire

Les groupes de contrôle (cgroups) vous permettent d'organiser les processus en groupes et d'imposer des limites strictes en matière de ressources. Introduits dans Linux 2.6.24, ils constituent la base des environnements d'exécution de conteneurs, notamment Docker, Podman, Kubernetes et LXC. Le noyau suit l'utilisation de la mémoire par cgroup, couvrant la mémoire anonyme, les pages sauvegardées sur disque et les objets du noyau. Si un cgroup atteint sa limite, le noyau récupère de la mémoire au sein de ce groupe ou déclenche un arrêt OOM au niveau du cgroup.

Les cgroups v1 et v2 diffèrent principalement par leur structure. La version v1 monte chaque contrôleur (mémoire, CPU, E/S) séparément sous /sys/fs/cgroup/<controller>/, ce qui entraîne un suivi incohérent des ressources. La v2 utilise une hiérarchie unifiée au niveau de /sys/fs/cgroup/. Kubernetes est passé à la version v2 par défaut dans la version 1.25 et a abandonné la prise en charge de la version v1 dans la version 1.31.

Pour vérifier quelle version votre système utilise :

stat -fc %T /sys/fs/cgroup/

cgroup2fs signifie v2 ; tmpfs signifie généralement v1.

Les commandes de mémoire clés dans cgroup v2 :

Règle pratique : réglez memory.high environ 10 à 20 % en dessous memory.max pour laisser au noyau une marge de récupération avant d'atteindre la limite stricte. Lors du dimensionnement memory.max, ajoutez 20 à 30 % au-dessus de l'utilisation maximale de l'application pour tenir compte du cache de pages, qui est décompté du total de la mémoire du cgroup.

Gérez les cgroups via systemd plutôt que d'écrire directement dans le système de fichiers du cgroup. Utilisez des directives de fichier d'unité telles que MemoryMax=, MemoryHigh=et MemoryMin= pour des limites persistantes. Pour des tests rapides :

systemd-run --scope -p MemoryMax=512M <command>

Pour les pools de workers de serveurs web, définir memory.oom.group=1 garantit une interruption propre si un worker dépasse sa limite — aucun processus orphelin n'est laissé derrière. Pour les moteurs de base de données, memory.min protège le pool de tampons contre la récupération en cas de pression à l'échelle du système.

Configuration de la mémoire en fonction du rôle du serveur

Les paramètres de mémoire appropriés dépendent de la fonction du serveur. Appliquer la même configuration à une base de données et à un serveur web PHP nuira à l'un d'entre eux.

Pour MySQL et PostgreSQL, allouez 50 à 70 % de la RAM disponible à innodb_buffer_pool_size, désactivez les Transparent Huge Pages pour réduire les pics de latence, et protégez le processus avec OOMScoreAdjust=-900 dans le fichier d'unité systemd.

Pour PHP-FPM, dimensionnez les pools de workers en fonction de l'utilisation réelle de la mémoire. Chaque worker utilise généralement entre 30 et 100 Mo. Divisez la RAM allouée par la taille moyenne d'un worker pour obtenir une pm.max_children . Utilisez memory.max dans les cgroups pour limiter le pool.

Pour les charges de travail à forte intensité d'écriture, définissez vm.dirty_ratio à environ 10 % et vm.dirty_background_ratio à 3 %. Cela permet de vider les pages modifiées plus fréquemment, évitant ainsi les longs blocages d'E/S.

Rendez le réglage du noyau persistant en enregistrant les paramètres dans /etc/sysctl.d/90-memory.conf. Les paramètres appliqués lors de l'exécution sont perdus au redémarrage.

Pour un résumé des valeurs recommandées par rôle :

Si vous exécutez des charges de travail à haute densité et avez besoin d'un serveur disposant de la marge nécessaire pour appliquer correctement ces politiques, les serveurs dédiés de FDC méritent votre attention.