Comment résoudre les problèmes de swappiness et de temps de démarrage sous Linux

J'ai récemment rencontré un autre problème intéressant dans la séquence de démarrage de Linux qui a un contournement et non une solution. Cela a commencé de manière assez inattendue.

J'écrivais quelques articles tout en mettant à jour ma copie personnelle de ma série de livres, "Utilisation et administration de Linux : zéro pour SysAdmin". J'avais quatre instances de LibreOffice Write prêtes à faire tout cela. J'avais trois machines virtuelles fonctionnant avec VirtualBox pour tester certaines des choses sur lesquelles j'écrivais. J'avais également LibreOffice Impress ouvert pour travailler sur une présentation sans rapport. J'aime écouter de la musique, c'est pourquoi j'avais l'un des nombreux onglets de Firefox ouverts sur Pandora, mon service de streaming musical de prédilection. J'ai ouvert plusieurs shells Bash à l'aide de Konsole avec de nombreux onglets et le client de messagerie en mode texte Alpine en un. Ensuite, il y avait les différents onglets du gestionnaire de fichiers Thunar.

Il se passait donc beaucoup de choses. Tout comme je le fais maintenant au moment où j’écris cet article.

Les symptômes

En utilisant ces sessions ouvertes, j'ai remarqué que les choses ralentissaient considérablement en attendant que le système écrive un document sur le SSD M.3, un processus qui aurait dû être très rapide. J'ai également remarqué que la musique était saccadée et s'éteignait complètement toutes les quelques minutes. La performance globale était généralement médiocre. J'ai commencé à penser que Fedora avait un sérieux problème.

Mon poste de travail principal, celui sur lequel je travaillais à l'époque, dispose de 64 Go de RAM et d'un Intel Core i9 Extreme avec 16 cœurs et Hyperthreading (32 processeurs) qui peut fonctionner jusqu'à 4,1 GHz en utilisant mon overclocking configuré. Je n’aurais donc dû subir aucun ralentissement – du moins c’est ce que je pensais à l’époque.

Déterminer le problème

Il n’a pas fallu longtemps pour trouver le problème car j’ai déjà rencontré des symptômes similaires sur des systèmes avec beaucoup moins de mémoire. Le problème ressemblait à des retards dus à l’échange de pages. Mais pourquoi?

J'ai commencé avec l'un de mes outils préférés pour déterminer les problèmes, htop. Cela montrait que le système utilisait 13,6 Go de mémoire pour les programmes et que la majeure partie du reste de la RAM était dans le cache et les tampons. Cela a également montré que l'échange était actif et qu'environ 253 Mo de données étaient stockés dans les partitions d'échange.

Date & Time: 2022-08-12 10:53:08
Uptime: 2 days, 23:47:15
Tasks: 200, 1559 thr, 371 kthr; 4 running
Load average: 3.97 3.05 2.08
   
Disk IO: 202.6% read: 687M write: 188K
Network: rx: 0KiB/s tx: 0KiB/s (0/0 packets)
Systemd: running (0/662 failed) (0/7912 jobs)     
Mem[|||||||##*@@@@@@@@@@@@@@@@@@@@@@@@@@    13.6G/62.5G]
Swp[||#                                      253M/18.0G]

Mais cela signifiait qu'il me restait encore beaucoup de mémoire que le système pouvait utiliser directement pour les programmes et les données et bien plus encore qu'il pouvait récupérer à partir du cache et des tampons. Alors pourquoi ce système a-t-il été échangé ?

Je me souviens avoir entendu parler du facteur « swappiness » lors d'un de mes cours de formation Red Hat. Mais c'était il y a longtemps. J'ai fait quelques recherches sur "swappiness" pour en savoir plus sur le paramètre du noyau vm.swappiness.

La valeur par défaut de ce paramètre du noyau est 60. Ce nombre est une valeur abstraite qui représente l'agressivité avec laquelle le noyau tente d'échanger. Contrairement à une compréhension courante mais erronée – y compris la mienne avant de réviser cet article – ce nombre ne représente pas un pourcentage de RAM. La valeur de vm.swappiness est utilisée dans une formule qui détermine plusieurs aspects de la façon dont l'échange est effectué par le noyau Linux.

Sur la base de mes lectures en ligne, j'ai découvert que 10 % est une meilleure valeur pour vm.swappiness pour de nombreux systèmes Linux dotés de grandes quantités de RAM. J'ai vérifié le paramètre de swappiness actuel sur mon système et il a été défini par défaut.

# sysctl vm.swappiness
vm.swappiness = 60

Il est temps de modifier ce paramètre du noyau.

Résoudre le problème

Je n'entrerai pas dans les détails sanglants, mais l'essentiel est que l'une ou l'autre des commandes suivantes, exécutées en tant que root, fera instantanément le travail sur un ordinateur Linux en cours d'exécution sans redémarrage.

# sysctl -w vm.swappiness=10

Vous pouvez également utiliser cette commande suivante pour faire la même chose.

# echo 10 > /proc/vm/swappiness

Tecmint propose un excellent article sur la définition des paramètres du noyau.

Les deux commandes modifient les paramètres du noyau actif dans le système de fichiers /proc. Après avoir exécuté l'une de ces commandes, vous devez exécuter la commande sysctl vm.swappiness pour vérifier que le paramètre du noyau a changé.

Mais ces commandes ne modifient que la valeur de swappiness pour le système en cours d'exécution. Un redémarrage ramène la valeur à sa valeur par défaut. Je devais m'assurer que ce changement soit rendu persistant lors des redémarrages.

Mais d'abord, l'échec

Pour modifier définitivement la variable vm.swappiness du noyau, j'ai utilisé la procédure décrite dans mon article précédent, Comment j'ai désactivé IPv6 sous Linux, pour ajouter la ligne suivante à la fin du /etc/ fichier par défaut/grub :

GRUB_CMDLINE_LINUX="vm.swappiness=1"

J'ai ensuite exécuté la commande grub2-mkconfig en tant que root pour reconstruire le fichier /boot/grub2/grub.cfg. Cependant, les tests avec des machines virtuelles et du matériel réel ont montré que cela ne fonctionnait pas et que la valeur de swappiness n'avait pas changé. J'ai donc essayé une autre approche.

Et le succès

Entre cet échec au démarrage, celui que je décris dans l'article Comment j'ai désactivé IPv6 sous Linux et d'autres problèmes de démarrage que j'ai explorés en raison de ces deux problèmes, j'ai décidé qu'il s'agissait d'un problème de timing de démarrage de Linux. . En d'autres termes, certains services requis, dont l'un pourrait être le réseau lui-même, n'étaient pas opérationnels, ce qui empêchait la validation de ces modifications d'options du noyau dans le système de fichiers /proc, ou bien elles étaient validées et puis écrasé au démarrage du service.

Je pourrais faire fonctionner tout cela comme ils le devraient en les ajoutant à un nouveau fichier, /etc/sysctl.d/local-sysctl.conf avec le contenu suivant, qui inclut toutes mes options de noyau local changements:

###############################################
#            local-sysctl.conf                #
#                                             #
# Local kernel option settings.               #
# Install this file in the /etc/sysctl.d      #
# directory.                                  #
#                                             #
# Use the command:                            #
# sysctl -p /etc/sysctl.d/local-sysctl.conf   #
# to activate.                                #
#                                             #
###############################################
###############################################
# Local Network settings                      #
# Specifically to disable IPV6                #
###############################################
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

###############################################
# Virtual Memory                              #
###############################################
# Set swappiness
vm.swappiness = 1

J'ai ensuite exécuté la commande suivante, qui a activé uniquement les options du noyau dans le fichier spécifié :

# sysctl -p /etc/sysctl.d/local-sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
vm.swappiness = 13

Il s'agit d'une approche plus ciblée pour définir les options du noyau que celle que j'ai utilisée dans mon article sur la désactivation d'IPv6.

Signaler le bug

Au moment d’écrire ces lignes, il n’existe pas de véritable solution à la cause première de ce problème, quelle qu’en soit la cause. Il existe un moyen de contourner temporairement le problème jusqu'à ce qu'un correctif soit fourni. J'ai utilisé le fichier /etc/sysctl.d/local-sysctl.conf que j'avais créé pour tester et ajouté un service systemd à exécuter à la fin de la séquence de démarrage, attendez quelques secondes, et exécutez sysctl sur ce nouveau fichier. Les détails sur la façon de procéder se trouvent dans l'article Comment j'ai désactivé IPv6 sous Linux.

J'avais déjà signalé cela sous le nom de bug 2103517 en utilisant Bugzilla de Red Hat en essayant de désactiver IPv6. J'ai ajouté ces nouvelles informations à ce bug pour m'assurer que mes dernières découvertes étaient disponibles pour les développeurs du noyau.

Vous pouvez suivre le lien pour consulter le rapport de bug. Vous n'avez pas besoin d'un compte pour consulter les rapports de bogues.

Dernières pensées

Après avoir expérimenté pour voir dans quelle mesure je pouvais reproduire les symptômes, ainsi que bien d'autres, j'ai déterminé que le paramètre vm.swappiness de 60 est beaucoup trop agressif pour de nombreux systèmes Linux à grande mémoire. Sans beaucoup plus de points de données que ceux de mes propres ordinateurs, tout ce que je peux provisoirement conclure, c'est que les systèmes dotés d'énormes quantités de RAM et rarement utilisés sont les principales victimes de ce problème.

La solution immédiate au problème des paramètres d'options du noyau local qui ne fonctionnent pas consiste à les définir après le démarrage. L'automatisation que j'ai implémentée est un bon exemple de la façon d'utiliser systemd pour remplacer l'ancien fichier de démarrage SystemV rc.local.

Ce bug n'avait pas été signalé auparavant. Il a fallu quelques jours d'expérimentation pour vérifier que le problème général dans lequel les options du noyau définies localement n'étaient pas définies ou conservées au démarrage était facilement reproductible sur plusieurs systèmes physiques et virtuels. À ce stade, j’ai pensé qu’il était important de signaler le bug pour m’assurer qu’il soit corrigé. Le signaler est une autre façon de redonner à la communauté Linux.