Optimisation des performances de systemd : un guide pratique étape par étape

Introduction

Lorsqu'un hôte Linux semble lent ou que les services mettent trop de temps à démarrer, systemd est souvent le premier endroit où les opérateurs regardent – et pour de bonnes raisons. C'est le système d'initialisation et le gestionnaire de services qui contrôle l'ordre de démarrage, supervise les démons et gère les limites de ressources. Mais ajuster systemd sans plan peut aggraver les choses.

Ce guide présente un processus sûr et pratique pour optimiser les performances de systemd. Il s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui doivent passer d'un problème observé à un résultat vérifié. Vous apprendrez à identifier votre version de systemd, à recueillir les bons diagnostics, à effectuer le plus petit changement justifié et à vérifier qu'il a fonctionné – avec des étapes de récupération si ce n'est pas le cas.

Nous couvrirons les concepts fondamentaux : l'accord de systemd, l'optimisation, la réduction de la latence et l'identification des goulots d'étranglement. Vous verrez des commandes concrètes, des extraits de configuration et des sorties attendues. Plus important encore, vous verrez comment les appliquer sans déstabiliser votre système.

Inventaire de la version et de l'environnement

Avant de changer quoi que ce soit, sachez exactement ce que vous exécutez. Cela évite les incohérences de version et vous aide à ne pas appliquer des conseils obsolètes. Commencez par des commandes en lecture seule pour établir un instantané de votre environnement.

Vérifier la version de systemd

Exécutez la commande suivante pour voir votre version de systemd et la distribution actuelle du système d'exploitation :

systemctl --version

Sortie attendue (extrait) :

systemd 252 (252.22-1~deb12u1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 +IDN +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

Cela vous indique la version (252), la révision de l'empaquetage et les fonctionnalités compilées. Comparez cela avec la documentation officielle de systemd pour votre distribution. La documentation contient souvent des paramètres de réglage spécifiques à la version. Par exemple, DefaultCPUAccounting=yes peut être disponible dans les versions plus récentes mais pas dans les anciennes.

Capturer la topologie et les limites de ressources

Ensuite, obtenez une vue de la structure des fichiers d'unité et des limites de ressources actuelles. Pour un service spécifique, disons nginx, utilisez :

systemctl cat nginx.service

Exemple de sortie :

# /lib/systemd/system/nginx.service
[Unit]
Description=The nginx HTTP and reverse proxy server
After=network.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/usr/sbin/nginx -s reload
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
TimeoutStopSec=5
KillMode=mixed

[Install]
WantedBy=multi-user.target

Notez le chemin du fichier : /lib/systemd/system/nginx.service est l'unité fournie par le fournisseur. Les remplacements personnalisés vont généralement dans /etc/systemd/system/nginx.service.d/override.conf. Comprendre cette superposition évite les modifications accidentelles de fichiers qu'une mise à jour de paquet pourrait écraser.

Vérifiez la comptabilité CPU et mémoire actuelle pour ce service avec :

systemctl show nginx.service -p CPUAccounting,MemoryAccounting,CPUShares,MemoryLimit

Exemple de sortie :

CPUAccounting=no
MemoryAccounting=no
CPUShares=1024
MemoryLimit=infinity

Si la comptabilité est désactivée, vous ne pouvez pas mesurer de manière fiable ce que le service consomme. C'est un prérequis pour l'optimisation.

Établissement d'une base de référence

Enregistrez un horodatage et sauvegardez toutes ces sorties. Créez un fichier comme baseline-$(date +%Y%m%d).txt dans votre répertoire de travail. Cette base de référence est votre point de restauration. Elle documente l'état actuel afin que vous puissiez comparer après les changements.

Exécutez également systemd-analyze pour obtenir les métriques de performance de démarrage :

systemd-analyze

Exemple de sortie :

Startup finished in 1.832s (kernel) + 4.502s (initrd) + 12.221s (userspace) = 18.555s
graphical.target reached after 12.211s in userspace

Cela vous donne un temps de démarrage total et une répartition. Pour un aperçu plus détaillé, exécutez :

systemd-analyze blame

Exemple de sortie (premières lignes) :

5.120s apt-daily.service
4.011s systemd-journal-flush.service
3.547s dev-sda1.device
1.983s networkd-dispatcher.service
1.345s udisks2.service

C'est le premier indicateur des goulots d'étranglement potentiels de systemd. Mais ne supposez pas qu'une unité lente est le problème – parfois elle dépend d'un autre service qui est lent.

Chemin de configuration sûr

Une fois que vous avez une base de référence et que vous avez identifié une unité suspecte, vous pouvez apporter des modifications. La règle d'or : effectuez le plus petit changement possible et le plus ciblé, et suivez-le afin de pouvoir l'annuler.

Utiliser des fichiers drop-in pour les remplacements

Supposons que apt-daily.service ralentit le démarrage et que vous voulez limiter son utilisation CPU. Ne modifiez pas le fichier d'unité d'origine. Créez plutôt un répertoire de remplacement drop-in :

sudo mkdir -p /etc/systemd/system/apt-daily.service.d/
sudo tee /etc/systemd/system/apt-daily.service.d/limits.conf <<'EOF'
[Service]
CPUQuota=20%
MemoryMax=256M
EOF
sudo systemctl daemon-reload

Cela fait que le service utilise au maximum 20 % d'un cœur CPU et plafonne la mémoire à 256 Mo. L'unité d'origine reste intacte.

Vérifier la syntaxe de la configuration

Avant de redémarrer quoi que ce soit, vérifiez l'unité fusionnée pour les erreurs :

systemd-analyze verify /etc/systemd/system/apt-daily.service.d/limits.conf

S'il n'y a pas de messages, la syntaxe est correcte. Vérifiez également que systemd accepte l'unité complète :

systemctl status apt-daily.service

Recherchez les lignes d'avertissement concernant des directives inconnues.

Appliquer et observer

Rechargez l'unité et démarrez-la (ou redémarrez-la si elle est déjà en cours d'exécution) :

sudo systemctl restart apt-daily.service

Vérifiez ensuite son utilisation réelle avec :

systemctl show apt-daily.service -p CPUUsageNSec,MemoryCurrent,CPUQuotaPerSecUSec

Exemple de sortie après une certaine activité :

CPUUsageNSec=151882302392
MemoryCurrent=103211008
CPUQuotaPerSecUSec=200ms

Le CPUUsageNSec est en nanosecondes cumulées ; le quota par seconde est affiché comme 200 ms, ce qui correspond à 20 % d'un cœur. Si le service a dépassé le quota, systemd le limite, et vous pouvez l'observer avec systemd-cgtop.

Documenter le changement et la récupération

Notez le changement dans un runbook simple. Par exemple :

• Changement : Ajouté CPUQuota=20% et MemoryMax=256M à apt-daily.service via un drop-in.
• Raison : Réduire le ralentissement du démarrage et les pics de mémoire.
• Vérification : systemctl show apt-daily.service -p CPUQuotaPerSecUSec renvoie 200ms ; le temps de démarrage a été réduit d'environ 1,2 seconde lors d'exécutions répétées de systemd-analyze.
• Récupération : Si le service échoue ou se comporte mal, supprimez le fichier drop-in avec sudo rm /etc/systemd/system/apt-daily.service.d/limits.conf, exécutez sudo systemctl daemon-reload, et redémarrez le service.

Cela vous évite d'être pris au dépourvu lorsqu'un changement cause un problème inattendu.

Vérification et diagnostics

La vérification ne consiste pas seulement à confirmer qu'un paramètre a été défini ; il s'agit de mesurer l'effet sur le système. Utilisez une combinaison des outils propres à systemd et des outils généraux de performance Linux.

Diagnostics spécifiques à systemd

• systemd-analyze pour le temps de démarrage et l'ordre de démarrage des unités. Après avoir apporté un changement, mesurez à nouveau le temps de démarrage et comparez.
• systemd-cgtop pour l'utilisation des ressources en direct par groupes de contrôle. Cela montre le CPU, la mémoire et les E/S par service en temps réel :

systemd-cgtop

Exemple de sortie (rafraîchit chaque seconde) :

Control Group                              Tasks   %CPU   Memory  Input/s Output/s
/                                          214     10.2   2.4G    -       -
/system.slice/nginx.service                8       2.1    330.5M  -       -
/system.slice/apt-daily.service            2       0.0    81.2M   -       -

Surveillez les services qui monopolisent constamment le CPU ou la mémoire. Utilisez -d 5 pour changer le délai à 5 secondes.

• journalctl pour les journaux de service. Pour un service spécifique :

journalctl -u nginx.service -n 50 --since today

Cela affiche les 50 dernières lignes de journal d'aujourd'hui. Recherchez les échecs de démarrage répétés ou les avertissements liés aux limites de ressources.

Recoupement avec les outils standard

Systemd exécute les services en tant que cgroups. Les outils standard comme top, htop, ps et iotop peuvent montrer des données par processus, mais ils peuvent ne pas agréger par service. Pour une vue complète, combinez-les.

Par exemple, pour voir quels processus appartiennent à un service, obtenez le chemin du cgroup :

systemctl show nginx.service -p ControlGroup

Sortie :

ControlGroup=/system.slice/nginx.service

Utilisez ensuite systemd-cgls pour lister l'arborescence des processus dans ce cgroup :

systemd-cgls /system.slice/nginx.service

Cela confirme que nginx et ses enfants sont dans le même groupe, ce qui est nécessaire pour que la comptabilité des ressources fonctionne.

Vérifications de latence et de débit

Si vous optimisez un service réseau, mesurez les temps de réponse avant et après. Pour nginx, vous pouvez utiliser curl pour mesurer le temps jusqu'au premier octet :

curl -o /dev/null -s -w 'Connect: %{time_connect}s, TTFB: %{time_starttransfer}s, Total: %{time_total}s\n' http://localhost/

Exemple de sortie :

Connect: 0.005s, TTFB: 0.021s, Total: 0.024s

Enregistrez cette base de référence. Après avoir modifié un paramètre systemd (par exemple, en augmentant LimitNOFILE ou en ajustant Nice), retestez et comparez. Utilisez un outil comme ab (ApacheBench) ou wrk pour des tests de charge plus approfondis.

Interprétation des résultats

Si votre changement n'a pas amélioré les performances, vérifiez si le goulot d'étranglement est ailleurs. Par exemple, si le CPU n'est pas saturé et que le démarrage est toujours lent, le retard peut être dû à l'attente du réseau ou du disque. Utilisez systemd-analyze critical-chain pour voir le chemin critique :

systemd-analyze critical-chain

Exemple de sortie :

graphical.target @12.211s
└─multi-user.target @12.211s
  └─docker.service @8.942s +3.268s
    └─network-online.target @8.901s +41ms
      └─NetworkManager-wait-online.service @6.811s +2.089s
        └─NetworkManager.service @6.403s +407ms
          └─basic.target @6.398s
            └─sockets.target @6.398s
              └─dbus.socket @6.387s
                └─sysinit.target @6.386s
                  └─systemd-timesyncd.service @6.117s +268ms
                    └─systemd-tmpfiles-setup.service @5.799s +316ms
                      └─local-fs.target @5.797s
                        └─boot.mount @5.690s +105ms

Cela montre que docker.service ajoute 3,2 secondes et attend le réseau en ligne. L'optimisation du démarrage peut impliquer de réduire cette attente, pas systemd lui-même.

Modes de défaillance et récupération

Même avec une planification minutieuse, les choses peuvent mal tourner. Voici les modes de défaillance courants et comment s'en remettre.

Erreur de syntaxe de configuration

Si vous faites une faute de frappe dans une directive, systemd rejettera l'unité. Vous pourriez voir :

systemctl status myapp.service

Sortie :

Warning: The unit file, source configuration file or drop-ins of myapp.service changed on disk. Run 'systemctl daemon-reload' to reload units.
myapp.service: Failed to parse resource value, ignoring: 20% of CPU

Récupération : Vérifiez le fichier d'unité et les drop-ins pour les erreurs de syntaxe. Utilisez systemd-analyze verify /path/to/unit (voir la section « Chemin de configuration sûr »). Corrigez la faute de frappe et exécutez systemctl daemon-reload.

Le service ne démarre pas

Si vous définissez une limite de ressources trop basse (par exemple, MemoryMax=10M pour un service qui a besoin de 50M), le service peut être tué par le tueur OOM du noyau. Dans journalctl, vous pourriez voir :

systemd[1]: myapp.service: Main process exited, code=killed, status=9/KILL
systemd[1]: myapp.service: Failed with result 'signal'.

Récupération : Supprimez immédiatement le remplacement, rechargez et redémarrez. Ensuite, étudiez les besoins réels en mémoire en utilisant systemctl show myapp.service -p MemoryCurrent au fil du temps pendant que le service fonctionne sans limites. Définissez une limite sûre avec une marge de manœuvre.

Blocage ou retard au démarrage

Si vous modifiez une unité critique (par exemple, multi-user.target), le système peut se bloquer au démarrage. Si vous le pouvez, interrompez le processus de démarrage en appuyant sur e dans le menu GRUB et en ajoutant systemd.unit=rescue.target à la ligne de commande du noyau. Cela démarre dans un shell de secours où vous pouvez annuler le changement.

Alternativement, utilisez une clé USB en direct ou un disque de secours pour monter votre système de fichiers racine et modifier ou supprimer le fichier incriminé sous /etc/systemd/system/.

Assurez-vous toujours d'avoir un chemin de retour en arrière testé. Pratiquez-le dans un environnement non productif avant de vous y fier.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour faire de l'optimisation de systemd un processus contrôlé. Chaque élément a un propriétaire clair et une fréquence de revue le cas échéant.

• [ ] 1. Identifier le problème de performance (Propriétaire : Responsable DevOps Jane Smith ; Revue : mensuelle ou sur incident). Définissez le symptôme : démarrage lent, CPU élevé, fuite de mémoire, délais d'attente des services. Quantifiez avec systemd-analyze ou des données de surveillance.
• [ ] 2. Établir une base de référence (Propriétaire : SRE de garde ; Revue : immédiatement avant tout changement). Exécutez systemctl --version, systemd-analyze, systemd-analyze blame et systemd-cgtop. Sauvegardez les sorties avec des horodatages.
• [ ] 3. Choisir le plus petit changement viable (Propriétaire : Ingénieur senior Tom Lee ; Revue : par changement). Préférez les remplacements drop-in dans /etc/systemd/system/unit.d/. Limitez la portée à un groupe de paramètres (CPU, mémoire, E/S ou délais d'attente).
• [ ] 4. Tester dans un environnement de préproduction (Propriétaire : Ingénieure de test Emily Chen ; Revue : avant la promotion). Si possible, répliquez l'unité et appliquez-y le changement. Exécutez les tests standard de votre service et comparez les performances.
• [ ] 5. Appliquer le changement avec un plan de retour en arrière (Propriétaire : Ingénieur de garde ; Revue : pendant la fenêtre de maintenance). Notez les étapes de retour en arrière : supprimez le fichier drop-in, exécutez systemctl daemon-reload, redémarrez le service.
• [ ] 6. Vérifier le résultat (Propriétaire : Analyste de performance Mike Brown ; Revue : dans les 24 heures). Comparez les nouvelles métriques à la base de référence. Confirmez qu'il n'y a pas de nouvelles erreurs dans les journaux. Utilisez systemd-analyze critical-chain pour vérifier les dépendances.
• [ ] 7. Documenter et partager (Propriétaire : Responsable DevOps Jane Smith ; Revue : dans la semaine). Ajoutez le changement aux runbooks, mettez à jour les tableaux de bord de surveillance et partagez les enseignements avec l'équipe.
• [ ] 8. Planifier une revue de suivi (Propriétaire : Gestionnaire de technologie ; Revue : après une semaine et un mois). Vérifiez si l'optimisation reste efficace. Les services et les charges de travail changent, donc des ajustements peuvent être nécessaires.

Chaque élément nécessite un propriétaire nommé, pas seulement une équipe. Cela garantit la responsabilité et évite que l'optimisation ne soit une action sans suivi.

Pièges courants et comment les éviter

Les pièges font partie de la courbe d'apprentissage, mais les connaître permet d'économiser du temps et d'éviter des pannes.

1. Modifier directement les fichiers d'unité du fournisseur. Pourquoi cela arrive : Il semble plus facile de modifier directement /lib/systemd/system/nginx.service, et de nombreux tutoriels le font encore. Évitement : Utilisez toujours des fichiers drop-in dans /etc/systemd/system/. Cela préserve les unités d'origine et simplifie le retour en arrière. Récupération : Si vous avez déjà modifié un fichier du fournisseur, restaurez-le depuis le paquet (par exemple, apt reinstall nginx pour Debian/Ubuntu) et déplacez vos paramètres personnalisés dans un drop-in.

2. Activer la comptabilité des ressources globalement sans besoin. Pourquoi cela arrive : Certains guides recommandent de définir DefaultCPUAccounting=yes dans /etc/systemd/system.conf pour activer la comptabilité partout. Cela consomme de la mémoire et peut légèrement ralentir les choses. Évitement : Activez la comptabilité par unité uniquement lorsque vous avez besoin de dépanner ou d'appliquer des limites. Pour la surveillance en production, envisagez des outils dédiés. Récupération : Si déjà activée globalement, commentez la ligne et redémarrez systemd (sudo systemctl daemon-reexec). Supprimez la comptabilité par unité si elle n'est plus utilisée.

3. Définir CPUQuota trop bas, affamer le service. Pourquoi cela arrive : Essayer de réduire l'utilisation du CPU sans mesurer le besoin réel. Un serveur web sous charge peut avoir besoin de plus de 10 % d'un cœur. Évitement : Mesurez l'utilisation réelle du CPU sur une période représentative avec systemd-cgtop ou des données de comptabilité. Définissez le quota avec une marge de 20 à 30 %. Récupération : Si le service devient insensible, supprimez le quota et redémarrez. Ensuite, réajustez en fonction de l'utilisation observée.

4. Ignorer les dépendances et l'ordre des services. Pourquoi cela arrive : Se concentrer sur une seule unité sans considérer ce dont elle dépend. Par exemple, accélérer nginx en activant un démarrage précoce, mais ensuite il échoue car le réseau n'est pas prêt. Évitement : Utilisez systemd-analyze critical-chain pour voir la chaîne de dépendances. Ajustez soigneusement les directives After= et Wants= et testez le comportement au redémarrage. Récupération : Si le démarrage casse, utilisez systemd.unit=rescue.target comme décrit précédemment, corrigez la dépendance et retestez avec plusieurs redémarrages.

5. Ne pas vérifier après un changement. Pourquoi cela arrive : Le changement est fait, le service démarre, et tout le monde suppose que cela a fonctionné. Évitement : Exécutez toujours des commandes de vérification et comparez à la base de référence. Mettez en place des vérifications automatisées si possible. Récupération : Si la vérification ne montre aucune amélioration ou une régression, revenez en arrière et réévaluez le problème.

6. Négliger la croissance du journal et des journaux. Pourquoi cela arrive : Le journal systemd peut devenir volumineux et consommer des E/S disque. Accorder systemd pour réduire la journalisation peut aider les performances, mais cela peut masquer des erreurs importantes. Évitement : Définissez des limites raisonnables via SystemMaxUse= dans /etc/systemd/journald.conf et effectuez une rotation régulière. Surveillez l'utilisation du disque. Récupération : Si vous avez complètement désactivé la journalisation et devez déboguer, réactivez-la avec Storage=persistent et redémarrez systemd-journald.

En anticipant ces pièges, vous pouvez optimiser systemd en toute confiance et garder vos systèmes stables.

Conclusion

L'optimisation des performances de systemd est une discipline : observer, émettre des hypothèses, changer de manière minimale, vérifier et documenter. Les commandes et techniques de ce guide vous donnent une base solide. N'oubliez pas que chaque recommandation doit être spécifique à la version, observable et réversible si possible.

Comme prochaine étape, choisissez une vérification à faible risque dans cet article. Cela pourrait être aussi simple que d'exécuter systemd-analyze blame sur une machine que vous suspectez d'être lente. Enregistrez l'état actuel, exécutez la vérification et comparez avec la sortie attendue. Identifiez ensuite un petit changement – peut-être ajouter un CPUQuota à un service bruyant – et suivez le chemin de configuration sûr.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. Appliquez cette discipline à systemd, et vos systèmes Linux fonctionneront plus facilement et de manière plus prévisible.