Guide avancé pour optimiser le noyau Linux et réduire la latence

Informatec Digital » Ressources » Guide avancé pour optimiser le noyau Linux et réduire la latence

Quand on parle de performances sous Linux, presque tout finit par converger vers le même point : le le noyau en tant que composant central qui contrôle la latence, la stabilité et l'utilisation des ressourcesUn réglage précis peut faire toute la différence entre un système qui se contente de « survivre » et un système qui répond de manière fluide sur les serveurs, les ordinateurs de bureau, les environnements cloud, ou même dans… matériel très ancien.

Ce guide explique comment Optimiser le noyau Linux pour minimiser la latence sans compromettre la sécurité ni la maintenabilitéNous aborderons tous les aspects, des concepts architecturaux de base aux réglages avec sysctl, en passant par la compilation de noyaux personnalisés, l'utilisation de correctifs en temps réel, l'optimisation pour les réseaux à faible latence (comme dans EC2), et les techniques de surveillance et d'évaluation comparative pour mesurer si vos modifications apportent réellement une amélioration.

Architecture du noyau Linux et points clés concernant la latence

Le noyau Linux agit comme une couche intermédiaire entre les applications et le matériel, gérant mémoire, processus, interruptions, pilotes et systèmes de fichiers. Sur conception monolithique mais modulaireGrâce aux modules chargeables, il vous permet d'activer ou de désactiver des fonctionnalités de manière flexible sans avoir à recompiler l'intégralité du système.

Pour comprendre l'origine des latences, il est essentiel de connaître plusieurs sous-systèmes : planificateur de processus (ordonnanceur)La gestion de la mémoire et des interruptions est cruciale. Un ordonnanceur mal configuré, une politique de mémoire trop restrictive ou un nombre excessif d'interruptions non contrôlées peuvent entraîner des temps de réponse lents, même avec du matériel puissant.

La configuration du noyau implique des options telles que CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY ou CONFIG_SMPCes facteurs déterminent dans quelle mesure le noyau peut être interrompu pour se consacrer à des tâches plus urgentes et comment il exploite les systèmes multicœurs. Le choix du modèle de préemption approprié modifie considérablement la latence perçue sur les ordinateurs de bureau, les serveurs à faible latence ou les systèmes industriels.

Dans les serveurs modernes, la topologie matérielle a également son importance : répartition des cœurs, des sockets, de NUMA et de la hiérarchie du cacheL'ajustement précis des affinités du processeur et des politiques NUMA (par exemple, en fixant les processus et la mémoire sur le même nœud) contribue à réduire les temps d'accès et à améliorer le taux de réussite du cache, ce qui est essentiel lorsque nous voulons minimiser les fluctuations et les latences imprévisibles.

De plus, l'interaction entre le planificateur du processeur et les sous-systèmes de Les E/S (disque et réseau) déterminent le débit et la latence de bout en bout. que les applications voient. Avant toute modification, il est conseillé de documenter l'état actuel (configuration du noyau, sysctl, GRUB, modules chargés) afin de pouvoir revenir rapidement en arrière si une modification dégrade les performances.

Ajustements via sysctl pour améliorer la latence et les performances

L'interface sysctl permet de modifier les paramètres du noyau à la volée. via /proc/sys, sans avoir à recompiler. C'est le point de départ idéal pour commencer l'optimisation sans se perdre dans les compilations.

Dans le domaine des réseaux, des paramètres tels que net.core.rmem_max, net.core.wmem_max ou net.ipv4.tcp_congestion_control Ils influent directement sur le débit, la latence et le comportement des connexions TCP. Un réglage précis des tampons et de l'algorithme de congestion est essentiel pour les serveurs web à fort trafic ou les instances cloud à faible latence.

Pour la mémoire, des valeurs telles que vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure ou vm.overcommit_memory Ils permettent de contrôler la quantité d'espace d'échange utilisée, la gestion du cache de pages et le comportement de la mémoire virtuelle. Réduire le taux d'échange (par exemple, à 10) permet généralement d'éviter une utilisation excessive de l'espace d'échange par le système, réduisant ainsi les pics de latence des E/S disque.

Si vous travaillez avec de grandes bases de données ou des applications qui utilisent d'importantes quantités de mémoire partagée, il est essentiel de procéder à un ajustement. noyau.shmmax, noyau.shmall et le nombre maximal de fichiers ouverts avec fs.file-max et fs.nr_openCes limites mal dimensionnées peuvent provoquer des goulots d'étranglement et des erreurs difficiles à diagnostiquer en charge.

La meilleure approche consiste à mettre en œuvre de petits changements, à mesurer leur impact à l'aide d'outils de suivi, et seulement ensuite Conservez-les dans /etc/sysctl.conf ou dans /etc/sysctl.d/Dans les environnements conteneurisés, n'oubliez pas que de nombreux paramètres du noyau sont globaux à l'hôte : les modifier sans précaution peut affecter tous les services, il est donc presque obligatoire de combiner sysctl avec les cgroups et les espaces de noms.

Compilation et maintenance de noyaux personnalisés

La compilation d'un noyau personnalisé reste un outil très puissant lorsque vous le souhaitez réduire la latence, supprimer les surcharges inutiles ou prendre en charge du matériel rareBien que les distributions soient fournies avec des noyaux assez polyvalents, dans certains cas, un noyau spécifique fait toute la différence.

Le flux de travail classique consiste à télécharger le code depuis kernel.org ou des arbres patchés comme xanmod ou liquorixet utiliser des outils comme make menuconfig pour choisir les options. Enregistrer le fichier .config dans votre propre dépôt git, avec les scripts de compilation, vous permet de reproduire les compilations et de maintenir la cohérence entre les versions.

Si vous utilisez Debian ou des dérivés, il est très pratique de compiler «dans le style Debian« Pour obtenir les paquets .deb du noyau, des en-têtes et des bibliothèques associées. Cela vous permet de déployer ce noyau personnalisé sur plusieurs machines simplement en installant les paquets et en gérant les versions avec votre propre dépôt. »

Dans la pratique, la compilation manuelle est souvent judicieuse lorsqu'on travaille avec matériel ancien ou très limitéUn exemple typique est un vieux netbook avec un processeur Atom et 1 Go de RAM, où un noyau générique moderne, rempli de pilotes et d'options serveur inutiles, introduit des latences et une consommation de processeur supplémentaire que vous ne pouvez pas vous permettre.

Une stratégie courante consiste à partir de la configuration actuelle du noyau (par exemple, en copiant le /configuration de démarrage), et à partir de là, recadrer ou ajuster. Vous pouvez modifier le modèle de préemption en «Noyau préemptible (bureau à faible latence)« pour privilégier la réponse interactive du bureau ou ajouter des planificateurs d'E/S spécifiques tels que BFQ sous la forme d'un module destiné à améliorer l'expérience sur les disques mécaniques.

Pour éviter de passer la moitié de sa vie à compiler, il est judicieux d'effectuer la compilation sur une machine plus puissante et, si nécessaire, d'utiliser compilation croisée (Par exemple, compiler un noyau 32 bits pour un Atom depuis un PC x86_64 en ajustant simplement l'architecture et les chaînes d'outils correspondantes). Il suffit ensuite d'installer les fichiers .deb sur la machine cible et d'ajouter l'entrée appropriée à GRUB.

Le plus délicat, c'est l'entretien : il est conseillé Tests du nouveau noyau sur des nœuds des îles Canaries, disposent de voies de restauration claires dans le gestionnaire de démarrage et enregistrent les journaux et les métriques pendant la transition afin de détecter les régressions en matière de performances ou de compatibilité des pilotes.

Modèles de préemption et correctifs PREEMPT_RT pour les systèmes à faible latence

Le modèle de préemption du noyau détermine dans quelle mesure une tâche en cours d'exécution peut être interrompue pour permettre à une tâche prioritaire de prendre le relais, ce qui affecte directement le latence de réponseCela inclut à la fois les options de configuration standard et les correctifs en temps réel.

Les noyaux génériques offrent plusieurs options : absence de préemption (privilégiant le débit du serveur), préemption volontaire et Noyau préemptible pour ordinateur de bureauCe paramètre privilégie la rapidité de réponse des applications interactives. Son ajustement peut améliorer considérablement les performances des ordinateurs de bureau, du système audio, voire même des machines plus anciennes fortement sollicitées.

Lorsque vous devez aller plus loin, les éléments suivants apparaissent : Correctifs PREEMPT et PREEMPT_RTCes modifications altèrent des portions importantes du noyau afin de minimiser les sections non préemptibles. PREEMPT_RT est destiné aux systèmes où la latence dans le pire des cas (et non seulement la latence moyenne) doit être très faible et prévisible : automatisation industrielle, audio professionnel, télécommunications ou trading haute fréquence.

La décision d'introduire PREEMPT_RT ne devrait pas être fondée sur la mode, mais sur mesures concrètes de latence et de gigueIl est tout d'abord conseillé d'utiliser pleinement les paramètres du planificateur, les affinités du processeur, sysctl et, le cas échéant, les configurations telles que le tickless dynamique avant de compliquer la maintenance avec un arbre RT.

La compatibilité doit également être prise en compte : certaines Les pilotes et les sous-systèmes ne sont pas entièrement adaptés au temps réel. et pourraient nécessiter des versions spécifiques ou des correctifs supplémentaires. La solution la plus judicieuse consiste à élaborer un plan de maintenance qui précise clairement quand et comment intégrer les nouvelles versions du noyau principal à la branche RT, laquelle se synchronise périodiquement mais reste légèrement en retrait.

Optimisation de la planification du processeur, fonctionnement sans interruption et isolation des cœurs

En plus de choisir le modèle de préemption, vous pouvez affiner la latence en jouant sur la planification du processeur et le comportement du minuteur du noyau, notamment dans les distributions orientées entreprise comme RHEL.

Red Hat Enterprise Linux 8, par exemple, est fourni avec un Le noyau est désactivé par défaut pour les processeurs inactifs.Cela réduit la consommation d'énergie en évitant les interruptions périodiques lorsque le cœur est inactif. Un mode peut être activé pour les charges de travail sensibles à la latence. dynamique sans tic-tac dans un ensemble de noyauxde sorte qu'un seul processeur (le « cœur principal ») gère la plupart des tâches temporelles, et que les autres soient aussi peu sujets aux interruptions périodiques que possible.

Cette configuration s'effectue en ajoutant les paramètres appropriés à la ligne de commande du noyau dans GRUBrégénérer la configuration, puis ajuster l'affinité des threads critiques du noyau, tels que les threads RCU ou les threads bdi-flush, de sorte qu'ils résident dans le noyau réservé à la maintenance.

Cette approche peut être complétée par le paramètre isolcpusCela permet d'isoler les cœurs des tâches utilisateur classiques. Dans les environnements à faible latence, il est fréquent de réserver plusieurs cœurs exclusivement à une application critique, tandis que le reste du système (démons, interruptions, etc.) est géré par d'autres cœurs.

Pour vérifier que le mode dynamique sans tic-tac fonctionne, des tests simples peuvent être exécutés avec stress ou des scripts qui occupent le processeur pendant une seconde et observent avec compteurs de tic-tac de minuterie Comment le nombre d'interruptions par seconde chute de plusieurs milliers à une seule dans les cœurs isolés, signe que le minuteur périodique a disparu.

Gestion de la mémoire et du stockage axée sur la latence

La manière dont le noyau gère la mémoire et les entrées/sorties disque a un impact énorme sur le latence perçue par les applicationsnotamment dans les bases de données et les services qui effectuent de nombreuses petites opérations fréquentes.

Du côté de la mémoire, réduire vm.swappiness minimiser l'utilisation de la mémoire d'échange (qui est presque toujours beaucoup plus lente que la RAM), vm.vfs_cache_pression Il contrôle la vitesse à laquelle le système tente d'effacer le cache des inodes et des entrées de répertoire, et vm.nr_pages_énormes Il permet de réserver des HugePages statiques pour les charges importantes telles que les bases de données ou les JVM, réduisant ainsi la surcharge du TLB.

En stockage, choisissez le Planificateur d'E/S approprié en fonction du type de disque C'est essentiel. Sur les SSD modernes, il est généralement conseillé d'utiliser... none o mq-deadlineEn revanche, pour les disques mécaniques et les systèmes multitâches, des algorithmes conçus pour l'équité pourraient être plus performants, tels que : BFQDe plus, le montage de systèmes de fichiers avec des options telles que noatime y nodiratime Évitez les écritures inutiles à chaque accès à un fichier ou un répertoire.

Concernant les systèmes de fichiers, ext4 et XFS Ces options restent les plus courantes : un système de fichiers ext4 bien configuré est un choix sûr, tandis que XFS tend à mieux gérer les pics de charge. Pour les scénarios très exigeants, la combinaison du RAID (RAID 10 pour les bases de données, RAID 0 pour le stockage temporaire) avec un bon planificateur peut réduire la latence moyenne et, surtout, la variabilité.

Optimisation du réseau et du noyau pour une faible latence sous Linux et EC2

Dans les applications réseau hautes performances, la latence dépend non seulement du matériel ou de la distance, mais aussi de comment la pile TCP/IP et le noyau lui-même sont configurésCela est particulièrement visible dans les instances cloud comme Amazon EC2 avec interfaces ENA.

Pour commencer, il est essentiel de réduire les facteurs externes tels que le nombre de sauts de réseau que les packages effectuent : en utilisant des topologies plus directes, des équilibreurs de charge proches du serveur dorsal ou des zones de disponibilité optimisées, les temps de trajet sont réduits en millisecondes avant même d’atteindre le système d’exploitation.

Au sein du noyau, la configuration réseau implique l'augmentation descripteurs de fichiers (ulimit -n), taille des tampons de réception et d'envoi avec net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmemet activer des options telles que TCP rapide ouvert pour réduire la latence d'établissement de la connexion.

Dans les interfaces AWS ENA, la modération des interruptions joue un rôle important : par défaut, le pilote regroupe les paquets pour réduire le nombre d’IRQ. rx-usecs et tx-usecsSi vous souhaitez réduire la latence au minimum absolu, vous pouvez désactiver cette modération en ethtool -CLe fait de régler les valeurs de rx-usecs et tx-usecs à zéro réduit la latence mais augmente la surcharge liée aux interruptions ; il faut donc trouver un équilibre en fonction de la charge.

Il peut également être utilisé irqbalance pour répartir les IRQ sur plusieurs cœurs, ou désactivez-le et définissez manuellement les affinités d'interruption et de file d'attente réseau (RSS/RPS) sur des cœurs spécifiques, ce qui est très courant dans les environnements à très faible latence ou lors de l'utilisation de DPDK et en ignorant une bonne partie de la pile du noyau.

Un autre paramètre à prendre en compte est le États C du processeurLes modes de veille profonde réduisent la consommation d'énergie, mais introduisent des délais lors du « réveil » du processeur. Pour réduire la latence de réponse, vous pouvez limiter ces modes de veille profonde, au prix d'une consommation d'énergie plus élevée et d'une moindre disponibilité du Turbo Boost sur les autres cœurs. Chaque environnement présente un compromis optimal entre la consommation d'énergie et le gain en microsecondes.

Optimisation du processeur, des services et des applications pour réduire la latence

Outre le noyau lui-même, l'environnement qui l'entoure a beaucoup à dire sur la latence globale : du noyau lui-même services actifs dans le système jusqu'à la configuration spécifique de chaque application.

Un serveur haute performance ne devrait exécuter que les démons qui sont vraiment nécessairesLes services tels que Bluetooth, l'impression ou la découverte automatique du réseau (CUPS, Avahi, etc.) sur les machines back-end consomment uniquement du processeur, de la mémoire et des E/S sans apporter aucun avantage. À revoir avec systemctl list-unit-files --state=enabled Et désactiver les fonctions inutiles est l'une des choses les moins coûteuses et les plus efficaces que vous puissiez faire.

Pour prioriser les processus critiques, vous pouvez utiliser des outils tels que renice, chrt et tasksetAjuster la priorité d'un processus (renice), lui donner une planification en temps réel (chrt -f 99) ou l'assigner à des cœurs spécifiques (taskset) réduit les interférences avec d'autres tâches, améliorant ainsi la prévisibilité du processeur pour les bases de données, la VoIP, le streaming ou les services de trading.

Au niveau applicatif, le réglage est tout aussi important que le réglage du noyau. Les serveurs Web tels que Nginx ou Apache Ils nécessitent un réglage précis des nœuds de calcul, de la persistance des connexions, des caches et de la compression. Les bases de données comme PostgreSQL ou MySQL Ils doivent revoir la taille des tampons, les points de contrôle, le pool de connexions et les paramètres d'écriture synchrone afin d'obtenir des latences faibles et stables.

Les JVM jouent également un rôle : le choix des ramasse-miettes comme G1GC ou ZGC Ajuster la taille du tas permet de réduire les pauses qui, vues de l'extérieur, apparaissent comme de la latence. Dans les environnements virtualisés et conteneurisés, une distribution adéquate est essentielle. quotas de vCPU, vRAM et E/S Cela évite les conflits silencieux qui se manifestent plus tard par des files d'attente interminables sur le disque ou une saturation du processeur.

Surveillance et analyse comparative du noyau et du système

Tous ces réglages sont inutiles si l'on ne mesure pas leur impact. La clé réside dans la combinaison. surveillance continue avec des tests de performance reproductiblesafin que chaque modification apportée au noyau ou à sysctl puisse être évaluée à l'aide de données objectives.

Pour visualiser l'état général du système, vous pouvez utiliser des outils classiques tels que : htop, vmstat, iotop o sarLorsque vous avez besoin de plus de détails, des outils spécifiques du noyau entrent en jeu, tels que : performance et ftracequi vous permettent de suivre avec une précision considérable le comportement du planificateur, des interruptions et des appels internes.

En environnement de production, il est recommandé de déployer des systèmes de métriques tels que Prometheus, collectd ou sysstat avec exportateurs qui exposent les compteurs du processeur, les E/S, les latences du disque et du réseau, les files d'attente des processus, etc. Ces données, visualisées dans Grafana ou des outils similaires, aident à détecter les régressions ou les anomalies avant que l'utilisateur final ne remarque les problèmes.

Pour l'analyse comparative, l'idée est de reproduire la charge de travail réelle et de comparer l'état « avant et après » chaque modification. Des outils tels que banc système (pour les processeurs et les bases de données), fio (pour disque) ou hyperf3 (Pour les réseaux) elles permettent la construction de scénarios reproductibles. La documentation est essentielle. versions du noyau, configurations sysctl, matériel et paramètres de test pour que les comparaisons aient du sens au fil du temps.

En pratique, l'optimisation du noyau Linux est un processus itératif : on teste différentes modifications, on mesure les résultats, on conserve celles qui apportent un réel bénéfice et on abandonne les autres. Grâce à une bonne gestion des changements, les améliorations apportées par les nouvelles versions du noyau (comme les récentes mises à jour concernant l'ordonnanceur, les graphismes, la consommation d'énergie ou le réseau) se traduisent par des gains concrets pour vos applications, qu'elles soient déployées sur des serveurs locaux, dans le cloud ou sur des stations de travail exigeantes.

La combinaison de connaissances en architecture du noyau, d'un réglage fin avec sysctl, d'une compilation contrôlée, d'une utilisation sélective de correctifs en temps réel et d'un bon système de métriques permet à un administrateur ou à une équipe d'exploitation d'atteindre Réponses plus rapides, latence réduite et stabilité globale améliorée sans avoir à changer de matériel à la moindre provocation ni à compromettre la sécurité du système.