Noyau Linux 6.x : nouveautés pertinentes pour les serveurs d'hébergement

Bien situer la version du noyau

Le terme « Linux 6.x » regroupe plusieurs versions majeures, et non un ensemble homogène de fonctionnalités. La branche principale (« mainline ») est celle maintenue par Linus Torvalds : après la période de fusion (« merge window »), on observe généralement des versions candidates (« release candidates ») jusqu'à la version finale. Il convient de les distinguer des branches « Stable » et « LTS », qui continuent à maintenir les noyaux publiés en y intégrant des corrections sélectionnées. Les noyaux des distributions suivent quant à eux leurs propres versions de paquets, leurs engagements de support et leurs décisions d'intégration.

C'est justement le cas pour les serveurs d'hébergement Backports Point essentiel : une distribution peut intégrer des fonctionnalités spécifiques, des améliorations de pilotes ou des correctifs de sécurité dans un noyau plus ancien, dont la maintenance est assurée à long terme. À l'inverse, elle peut désactiver des fonctionnalités, modifier des correctifs ou les limiter par le biais de la configuration. Un numéro de version ne permet donc pas de déduire ni l'ensemble complet des fonctionnalités, ni l'impact concret sur le fonctionnement.

La commande uname -r Il permet d'identifier la chaîne de version en cours et constitue un point de départ utile pour l'inventaire et la comparaison des paquets. Il ne prouve toutefois pas qu'une fonction soit intégrée au code source, activée lors de l'exécution ou accessible par une application. De même, une nouvelle version du noyau ne remplace pas une vérification de la configuration et de la documentation fournies par le distributeur.

Pour effectuer une analyse fiable, tu dois examiner plusieurs niveaux : la distribution et l'état des paquets, la configuration du noyau, les paramètres de démarrage et les interfaces d'exécution existantes. À cela s'ajoutent le matériel, le micrologiciel et les pilotes, notamment en matière de stockage ou de virtualisation. Enfin, l'application utilisée doit effectivement utiliser une interface ; une fonction existante du noyau ne modifie pas automatiquement un serveur web.

Cet article ne suit donc pas une chronologie complète des versions. Il passe en revue les fonctionnalités pertinentes pour l'exploitation des noyaux 6.x actuels. Toutes n'ont pas été introduites pour la première fois dans la série 6.x ; ce qui importe, ce sont les fonctionnalités disponibles dans le noyau concerné, les extensions possibles et les répercussions sur le comportement de la mémoire, la concurrence CPU, l'isolation des processus et la maintenance.

Quatre domaines d'activité dans le secteur de l'hébergement

Quatre domaines d'exploitation revêtent une importance particulière pour les serveurs d'hébergement : pression de stockage, concurrence CPU, isolation supplémentaire des processus et maintenance. Il ne s'agit pas ici d'activer le plus grand nombre possible de fonctionnalités du noyau, mais de disposer d'outils adaptés à un problème observé. Les pools PHP-FPM, les bases de données, les caches, les tâches par lots et les workers spécialisés posent des exigences différentes qui ne peuvent être déduites de la seule version du noyau.

cgroup v2 Il s'agit d'un thème transversal, mais pas d'une nouveauté de la série 6.x. La hiérarchie structure les ressources de mémoire et de CPU pour les services, les conteneurs ou les groupes de clients. Il convient de vérifier, au niveau du montage cgroup-v2 correspondant, quels contrôleurs sont disponibles et activés dans une sous-hiérarchie. Un serveur web dédié nécessite donc une évaluation différente de celle d’un hôte de conteneurs ou de machines virtuelles.

Le tableau distingue délibérément la configuration de compilation, l'activation au démarrage, l'interface d'exécution et l'utilisation effective. Une fonctionnalité peut être présente dans le noyau, mais être désactivée ou sans importance pour l'application. De même, les distributions peuvent rétroporter des fonctionnalités. Évaluez donc les modifications en fonction de l'historique de charge, de la structure des cgroups, du matériel et des mesures d'application, plutôt qu'en fonction du numéro de version le plus élevé disponible.

Pression de la mémoire et récupération de pages

Linux utilise volontiers la mémoire vive libre comme cache de fichiers. Une mémoire RAM fortement occupée n'est donc pas en soi un problème ni un signe de gaspillage de mémoire : les pages de fichiers mises en cache peuvent être récupérées en cas de besoin. Pour le diagnostic, ce sont plutôt l'évolution et les conséquences de la charge qui comptent, comme les temps de réponse, l'activité de la page de swap, les journaux d'erreurs et les interruptions de processus.

C'est la pression dans le réservoir qui détermine Récupération de pages , quelles pages peuvent être supprimées du cache ou, le cas échéant, transférées hors du cache. Le noyau peut effectuer cette tâche de manière asynchrone via kswapd traiter. Lorsqu'un processus doit récupérer lui-même des pages lors d'une requête de mémoire, la documentation du noyau parle de « récupération directe » ; celle-ci peut affecter le processus demandeur et, par conséquent, les latences observées.

Les signaux d'alerte se manifestent généralement sous forme de combinaison : un transfert vers ou depuis la mémoire swap prolongé, des événements OOM, des temps d'attente croissants et des erreurs au niveau des applications méritent d'être replacés sur une même chronologie. En revanche, un pic ponctuel peut être dû à un traitement par lots planifié. De même, un service de cache utilisant une grande partie de la mémoire vive n'est pas automatiquement en cause si son cgroup et les autres processus conservent une capacité d'action suffisante.

cgroup v2 complète la vue globale par des limites au niveau des services ou des conteneurs. Le contrôleur de mémoire fournit des compteurs d'événements ; memory.events est hiérarchique, tandis que memory.events.local n'affiche que les événements locaux du cgroup concerné. Cela permet de déterminer si un problème est lié à la limite de son propre service ou à la charge au sein d'une structure de niveau supérieur.

Ces principes de base ne justifient pas encore le tuning. Avant de modifier les limites, la stratégie de swap ou les interfaces du noyau, vous devez classer les sources de charge, l'affectation aux cgroups et les corrélations temporelles. Une limite de mémoire trop stricte, en particulier, peut entraîner l’échec prématuré d’un service au lieu de résoudre le pic de charge sous-jacent. Seul le diagnostic permet de déterminer si une modification dispose d’un levier technique approprié.

Vérification ciblée des LRU multi-gènes

Multi-Gen LRU est une implémentation alternative de Récupération de pages et est décrit dans la documentation du noyau abordée ici à partir de Linux 6.1. En cas de pression sur la mémoire, le noyau doit décider quelles pages du cache de fichiers ou de la mémoire anonyme peuvent être récupérées. À cette fin, le Multi-Gen LRU classe les pages en générations en fonction de leur ancienneté d’accès et tient compte des modèles d’accès, afin que les pages fréquemment utilisées soient moins susceptibles d’être sélectionnées pour la récupération.

Cela s'applique à un serveur d'hébergement web très sollicité, sur lequel les pools PHP-FPM, une base de données et un service de mise en cache mobilisent simultanément de la mémoire vive. Cette fonction peut modifier le comportement de la commande « reclaim », mais elle ne constitue ni une extension de mémoire ni une garantie de temps de réponse plus courts. La charge de travail, la quantité de RAM, l'espace d'échange, le stockage de masse et les limites cgroup des services continuent de déterminer si et dans quelle mesure un effet se fait sentir.

Avant chaque évaluation, tu dois d'abord vérifier si l'interface d'exécution est présente et lisible. La documentation actuelle du noyau mentionne les options de configuration suivantes à cet effet : CONFIG_LRU_GEN et CONFIG_LRU_GEN_ENABLED ainsi que le chemin d'accès sous /sys/kernel/mm/lru_gen/. Un noyau de distribution peut rétroporter des versions de fonctionnalités ou les configurer différemment ; le numéro de version ne constitue donc pas à lui seul une preuve fiable.

test -r /sys/kernel/mm/lru_gen/enabled && cat /sys/kernel/mm/lru_gen/enabled

Une sortie permet dans un premier temps de vérifier uniquement que l'interface sysfs documentée existe et est accessible en lecture. La valeur binaire est déterminante pour l'état d'activation : 0x0001 Il s'agit du commutateur principal de Multi-Gen LRU. Si ce bit est absent, le fichier peut indiquer que le commutateur principal est désactivé, même si l'interface est disponible ; les autres bits concernent des composants supplémentaires. Même si ce bit principal est activé, cela ne signifie pas pour autant qu'il soit recommandé de modifier la valeur en production.

Les accès en écriture à sysfs ne font donc pas partie des réglages standard. Commencez par enregistrer des séries chronologiques concernant le « reclaim », la mémoire swap, les latences et les événements cgroup ; en cas de modification justifiée, consignez la valeur initiale et définissez un plan de retour en arrière. Cela permet de vérifier si le problème observé a réellement évolué ou si plusieurs paramètres ont simplement été modifiés simultanément.

Tu dois te montrer particulièrement prudent lorsque les limites de stockage sont restreintes et que les services sont surchargés. Une modification de l'algorithme de récupération ne corrige pas les pools de workers PHP trop importants, les caches de base de données inadaptés ou l'absence de séparation entre des clients concurrents. La marche à suivre recommandée est la suivante : déterminer la cause et le cgroup concerné, limiter ou répartir la charge, puis seulement ensuite évaluer une fonction du noyau disponible comme facteur d’influence potentiel.

Identifier avec certitude les problèmes de mémoire

La mémoire RAM occupée n'est pas en soi un problème : Linux utilise la mémoire libre de manière ciblée comme cache de fichiers. Il convient plutôt d'intervenir lorsque les besoins en Reclaim direct fonctionnent, l'activité de swap augmente, des événements OOM se produisent ou les requêtes deviennent simultanément plus lentes. Récupération asynchrone via kswapd fonctionne en arrière-plan ; la récupération directe, en revanche, s'effectue dans le contexte de la tâche qui sollicite la mémoire et peut retarder son exécution.

Le fichier des événements memory.events compte les événements de manière hiérarchique, c'est-à-dire en incluant les cgroups subordonnés. Pour une vue exclusivement locale, on utilise memory.events.local prêt. high signifie une limitation et une récupération directe en cas de dépassement de memory.high, alors que oom compte comme une allocation ayant failli échouer en raison de la limite du cgroup. oom_kill En revanche, il comptabilise les processus de ce cgroup qui ont été interrompus par un OOM-Killer, quel qu'il soit.

Commencez le diagnostic par une identification claire : quel service ou conteneur appartient au cgroup suspect, quand les événements se sont-ils produits et quels signaux d'application ont été observés simultanément ? Comparez ensuite les compteurs locaux et hiérarchiques, le journal système, l'historique de la mémoire swap, ainsi que les latences HTTP, les temps d'attente des bases de données ou les taux d'erreur. En cas de situation OOM (Out of Memory), il convient en outre de déterminer si les données indiquent un problème lié au cgroup ou une éventuelle pénurie globale de mémoire.

La valeur memory.max Il s'agit d'une limite stricte du cgroup et non d'une première mesure par défaut. Une limite plus stricte peut protéger les clients, mais peut également faire basculer une application plus tôt dans des situations OOM ; une limite plus élevée peut accentuer l'éviction des services voisins. Vérifie donc d’abord le nombre de workers, la taille des caches, les pics de charge et la structure des cgroups. Ne modifie ensuite qu’un seul paramètre justifié, en prévoyant une période d’observation et un plan de retour en arrière.

Comprendre l'EEVDF et la concurrence entre les CPU

La documentation officielle actuelle du noyau fixe le début de la transition vers EEVDF Linux 6.6. L'algorithme « Earliest Eligible Virtual Deadline First » modifie la sélection des tâches normales planifiées de manière équitable : il prend en compte le temps d'exécution virtuel, le décalage par rapport à la répartition idéale et les délais virtuels. Les tâches éligibles ayant le délai virtuel le plus proche peuvent ainsi obtenir en premier le temps CPU.

Le terme „ transition “ est important. L'EEVDF ne remplace pas le choix de la classe Fair Scheduling au sens où toutes les structures de données, interfaces et concepts historiquement désignés sous le nom de CFS disparaîtraient pour autant. La documentation actuelle continue d’ailleurs de comparer l’EEVDF au CFS. Pour un noyau de distribution donné, il convient donc de vérifier l’état de ses correctifs et de ses fonctionnalités intégrés, plutôt que de se baser uniquement sur 6.6 ou supérieur, pour en déduire un comportement totalement homogène.

En matière d'hébergement, cette modification est particulièrement pertinente en cas de charge mixte. Les requêtes Web, les opérations sur les bases de données et la surveillance entrent par exemple en concurrence avec les importations, la compression ou les sauvegardes. Un profil de latence différent entre les versions du noyau est possible, mais cela ne se traduit pas automatiquement par un débit global plus élevé. Le planificateur ne résout pas les problèmes liés aux cœurs saturés en permanence, aux processus bloqués, aux temps d'attente d'E/S et aux configurations d'applications inadaptées.

La séparation opérationnelle continue de s'effectuer selon les limites des services et des plateformes. Les pondérations CPU influencent la répartition relative en cas de concurrence, tandis que les quotas peuvent limiter le temps de calcul disponible. Si une charge Web sensible à la latence doit être séparée de manière fiable de travaux par lots volumineux, une machine virtuelle dédiée ou un hôte distinct peut également s’avérer approprié. EEVDF remplace ces solutions Planification des ressources pas.

Avant d'interroger cgroup.controllers tu dois vérifier si cgroup v2 est monté et, le cas échéant, à quel emplacement. La procédure suivante recherche le point de montage de cgroup v2, plutôt que le chemin d'accès habituel /sys/fs/cgroup à supposer. Sur un système exclusivement cgroup-v1, la variable reste vide ; dans le cas d'une hiérarchie hybride, elle n'indique que le montage v2 détecté.

uname -r
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS
CG2=$(findmnt -n -t cgroup2 -o TARGET | head -n 1)
if [ -n "$CG2" ] && [ -r "$CG2/cgroup.controllers" ]; then
    printf 'cgroup-v2 mount: %s\n' "$CG2"
    cat "$CG2/cgroup.controllers"
    test -r "$CG2/cgroup.subtree_control" && cat "$CG2/cgroup.subtree_control"
fi
systemd-cgtop

uname -r indique uniquement la chaîne de version actuelle. cgroup.controllers répertorie les contrôleurs disponibles pour activation au sein de ce cgroup précis ; cela ne garantit pas qu’ils aient été activés dans les sous-hiérarchies concernées. Pour cela, il faut notamment utiliser cgroup.subtree_control à vérifier à chaque niveau hiérarchique. Les contrôleurs sont validés selon une approche descendante, de sorte qu’un cgroup enfant ne peut transmettre que les contrôleurs fournis par le nœud parent.

systemd-cgtop ne fournit également qu’un aperçu ponctuel et ne constitue pas une analyse des causes. Collectez les données relatives à l’utilisation du processeur par groupe de services, aux latences des requêtes, aux durées d’exécution des tâches batch et, le cas échéant, aux temps d’attente d’E/S sur plusieurs phases de charge comparables. Si des retards ne surviennent que pendant une sauvegarde, la fenêtre de temps de celle-ci, sa charge CPU ou son quota constituent généralement des leviers d’action initiaux plus concrets qu’un éventuel réglage du planificateur.

Landlock pour les travailleurs spécialisés

Landlock a été introduit pour la première fois avec Linux 5.13 et ne constitue donc pas une nouveauté propre à la série 6.x. Dans les noyaux 6.x, différents niveaux d'ABI étendus sont disponibles selon la version et le noyau de la distribution. Cette fonctionnalité constitue un mécanisme de sécurité complémentaire permettant à un processus de s'imposer des restrictions supplémentaires.

En tant que module de sécurité Linux empilable, Landlock s'ajoute aux politiques d'accès déjà en vigueur ; il ne remplace ni les droits d'accès aux fichiers Unix, ni SELinux, ni AppArmor, ni les espaces de noms, ni les conteneurs. Les règles peuvent notamment limiter les accès au système de fichiers et sont transmises aux processus enfants lancés par la suite. Les fonctionnalités pratiques dépendent de l’ABI disponible et de la configuration du noyau.

Il est judicieux de Enclavé notamment pour des processus individuels développés en interne ou sélectionnés de manière ciblée. Un convertisseur destiné aux téléchargements des clients pourrait ne lire les fichiers que dans un dossier d'entrée et n'enregistrer les résultats que dans un dossier de sortie. Même en cas de dysfonctionnement du service, celui-ci ne doit pouvoir accéder ni aux clés SSH, ni aux secrets d’application, ni aux chemins d’accès généraux du système. Cette restriction vient compléter une attribution rigoureuse des droits ; elle ne la rend pas superflue.

Une règle productive ne doit pas reposer uniquement sur un noyau actuel. Landlock dispose de plusieurs versions ABI ; une application doit interroger l'ABI disponible au moment de l'exécution et ne demander que les droits d'accès ou les fonctions pris en charge par cette ABI. Elle peut ainsi fonctionner de manière dégradée sur des systèmes plus anciens, au lieu de cesser complètement de fonctionner en raison d'une interface indisponible.

Par ailleurs, handled_access_fs définit explicitement les accès au système de fichiers gérés par un ensemble de règles et refusés par défaut en l'absence de règle correspondante. Cet accord explicite entre l'application et le noyau empêche qu'un bac à sable ne devienne plus restrictif à l'insu de l'utilisateur, simplement à la suite d'une mise à jour du système, ce qui entraînerait des dysfonctionnements des applications. La consultation de l’ABI et les droits explicitement gérés vont donc de pair, mais répondent à des enjeux de compatibilité différents.

Pour le convertisseur de fichiers, cela se traduit par une mise en place progressive : déterminer les répertoires de lecture, d'écriture et de travail nécessaires à partir du déroulement réel du processus, prendre en compte les chemins d'erreur et effectuer d'abord des tests dans l'environnement de préproduction. Une politique succincte ne constituerait pas une recette de production fiable, car les fichiers temporaires, les bibliothèques externes et les programmes auxiliaires lancés peuvent nécessiter des accès supplémentaires. L'article consacré à Renforcement du noyau pour les serveurs d'hébergement.

Une prudence particulière s'impose dans les cas suivants : OverlayFS. Les règles applicables à une couche de superposition ne restreignent pas automatiquement la hiérarchie de montage fusionnée, et inversement. Les environnements de conteneurs et de build utilisant des overlays nécessitent donc une vérification spécifique des montages et des chemins d’accès concrets. Landlock constitue dans ce cas une couche supplémentaire possible, mais ne garantit pas une séparation générale des mandants et ne remplace pas un concept de conteneurs ou d’autorisations solide.

DAMON : réservé aux cas particuliers

DAMON et les mécanismes de récupération qui en découlent ne peuvent pas être considérés de manière générale comme des fonctionnalités introduites pour la première fois avec Linux 6.x. Pour les administrateurs, ce qui compte, c'est le niveau de fonctionnalité du noyau 6.x ou de la distribution concrètement utilisé. DAMON surveille les accès à la mémoire dans le but de pouvoir classer les zones en fonction de leur comportement d'utilisation.

Partant de là, on tente DAMON_RECLAIM, afin de récupérer de manière proactive de la mémoire inutilisée depuis longtemps en exerçant une légère pression. Ce procédé vient compléter la récupération normale basée sur l'algorithme LRU ; il n'est pas destiné à la remplacer. La documentation du noyau l'associe aux systèmes de mémoire surchargés en général et cite comme exemple la virtualisation basée sur le rapport des pages libres.

Dans ce scénario de virtualisation, le niveau est déterminant : les invités signalent à l'hôte les pages de mémoire libres, que celui-ci peut attribuer à d'autres invités. Si un invité ne signale que peu de mémoire libre alors qu'il conserve des pages inutilisées depuis longtemps, le « reclaim » proactif peut en tant qu'invité contribuer à signaler davantage de pages libres à l'hôte. DAMON_RECLAIM ne constitue donc pas, sans vérification supplémentaire, une solution côté hôte pour la mémoire vive inutilisée des invités.

Pour un serveur Web ou une base de données isolé(e), il ne s'agit donc pas d'une mesure standard. Même dans les environnements virtualisés, il faut d’abord déterminer clairement à quel niveau la pression s’exerce et si elle est réellement due à des zones inutilisées depuis longtemps. Des goulots d’étranglement au niveau du processeur, un stockage lent, des limites de cgroup inadaptées ou des caches d’application actifs peuvent expliquer ces mêmes symptômes, sans que la récupération proactive ne soit la solution appropriée.

Les quotas, les limites d'âge et les seuils déterminent quand et dans quelle mesure DAMON_RECLAIM fonctionne. Il ne s'agit pas de valeurs par défaut transférables : une sélection trop agressive peut évincer prématurément un cache de fichiers utile ou des pages de mémoire régulièrement sollicitées. Cela peut déclencher des opérations d'E/S supplémentaires et mobiliser du temps CPU pour un nouveau traitement, alors même que la mémoire nominalement libre augmente.

Une décision fondée nécessite donc des mesures s'appuyant sur des repères clairs, tels que l'espace de stockage libre déclaré par l'utilisateur, l'activité de récupération, le comportement de swap, la latence de stockage et les temps de réponse des applications. Testez d’abord les modifications dans un environnement de préproduction comparable, définissez un plan de repli et observez-les pendant des phases de charge représentatives. Si ces conditions ne sont pas remplies ou si la cause de la pression sur le stockage n’est pas clarifiée, DAMON reste délibérément désactivé.

Mises à jour, correctifs en direct et redémarrages

La maintenance du noyau commence par la vérification de la correspondance entre l'avis de sécurité, le paquet installé et le noyau effectivement en cours d'exécution. Vérifiez ensuite dans les notes de votre distribution quel correctif est prévu pour cette branche précise du noyau et si un redémarrage est nécessaire. Un numéro de version 6.x plus élevé ne prouve pas à lui seul ni la présence du correctif, ni la disponibilité d'un correctif « live » adapté ; les correctifs de sécurité peuvent également être portés vers des noyaux de distribution plus anciens.

Voir aussi Modification en temps réel Ce concept n'a pas été introduit pour la première fois avec Linux 6.x. L'infrastructure propre aux noyaux 6.x permet d'appliquer certaines modifications du noyau à la volée. Les correctifs cumulatifs « livepatches » peuvent ainsi remplacer de manière atomique un ancien correctif par un plus récent. Les limites documentées concernent notamment les changements d'état, les callbacks et le retour à un correctif antérieur.

Pour savoir si un correctif « live » adapté est disponible pour un noyau de distribution spécifique, il convient de vérifier l'offre correspondante et les autorisations accordées par le fournisseur. L’infrastructure générale du noyau n’implique ni que chaque correctif de sécurité soit disponible en direct, ni qu’un correctif appliqué remplace définitivement une mise à jour complète du noyau. Continuez donc à prévoir des fenêtres de maintenance régulières.

Évalue d'abord le niveau d'urgence et l'impact d'une mise à jour, puis compare la version des paquets et celle du noyau en cours d'exécution, et examine l'offre concrète de Livepatch. Après une mise à jour régulière du noyau suivie d'un redémarrage, vérifiez si le noyau attendu est actif et si les services critiques, les chemins réseau, les sauvegardes et la surveillance fonctionnent correctement. Cette vérification fait partie de la procédure de maintenance et ne doit pas être confondue avec la simple accessibilité du serveur.

A redémarrage prévu peut s'avérer nécessaire malgré le Livepatching. Les modifications apportées aux paramètres de démarrage du noyau ne prennent généralement effet qu'au prochain démarrage. En ce qui concerne les pilotes, le micrologiciel des périphériques et le matériel, la procédure dépend en revanche du composant, de son intégration et du processus de fabrication : dans certains cas, un redémarrage du module, du périphérique ou du service suffit, tandis que dans d'autres, un redémarrage complet de l'hôte est nécessaire.

L'article complémentaire sur Corrections à chaud sur les serveurs AlmaLinux traite d'une mise en œuvre concrète dépendante de la distribution. Ne transposez pas ces procédures telles quelles à d'autres branches du noyau ou à d'autres fournisseurs sans les avoir vérifiées. Ce sont les paquets, les versions du noyau prises en charge et les consignes d'utilisation de la plateforme effectivement utilisée qui font autorité.

• Ne rien changer délibérément si le dysfonctionnement observé n'a pas encore de cause identifiable.
• Ne pas prévoir de correctif en direct ni de modification du noyau sans test de staging approprié et sans avoir prévu une solution de repli documentée.
• Ne pas activer de fonctionnalité si l'application ou la plateforme concernée n'utilise pas son interface.
• Ne pas supposer, en l'absence de fenêtre de maintenance, que le « live patching » couvre toutes les mises à jour du noyau.