Planification de capacité avec systemd : exemples pratiques pour la gestion des ressources

Introduction

systemd est le système d'initialisation par défaut sur la plupart des distributions Linux modernes, et il fait bien plus que démarrer et arrêter des services. Il fournit également une interface unifiée pour gérer les ressources des services : CPU, mémoire, E/S, tâches, etc. La planification de capacité dans systemd consiste à comprendre la quantité de ressources dont un service a besoin, à définir des limites appropriées et à surveiller l'utilisation afin d'éviter qu'un service n'affame les autres ou ne fasse planter l'hôte.

Ce guide s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui doivent maintenir la stabilité des services de production sans surprovisionner le matériel. Il couvre l'inspection de la consommation actuelle, la définition de contrôles de ressources via des fichiers d'unité ou des commandes, la vérification de l'application des limites, le diagnostic des échecs courants et la récupération en cas de problème.

L'approche privilégiée tout au long de cet article est la sécurité opérationnelle : toujours observer avant de modifier, effectuer un seul changement ciblé à la fois, utiliser des valeurs fictives au lieu de secrets réels, vérifier immédiatement le résultat et documenter un plan de retour en arrière.

Inventaire de la version et de l'environnement

Avant de toucher aux limites, sachez exactement avec quoi vous travaillez. Commencez par la version de systemd et les informations de base sur l'hôte.

systemctl --version

La sortie attendue inclut des lignes telles que :

systemd 252 (252.5-1ubuntu1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GSS +CRYPTO +GNUTLS +SYNTHETIC_ERRNO +WATCH_QUEUE

Vérifiez également la version du noyau, car certains contrôleurs de ressources dépendent du support du noyau :

uname -r

Une réponse typique sur Ubuntu 22.04 est 5.15.0-91-generic. Si vous savez que vous avez besoin d'une version de cgroup ou d'un contrôleur spécifique, vérifiez-le tôt. Par exemple, vérifiez la version de cgroup utilisée :

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

Sur un système avec cgroup v2, cela affiche cgroup2fs. Sur cgroup v1, cela affiche tmpfs.

Pour chaque service que vous prévoyez d'ajuster, enregistrez son fichier d'unité actuellement actif et tous les fichiers de surcharge. Pour un service nommé webapp :

systemctl cat webapp

La sortie montre le fichier d'unité principal et les fichiers de redéfinition sous /etc/systemd/system/webapp.service.d/. C'est là que vous ajouterez souvent des limites ; savoir si une surcharge existe déjà évite d'écraser un travail antérieur.

Capturez un instantané de l'utilisation actuelle des ressources comme référence. Utilisez systemctl show pour voir les propriétés effectives, y compris la mémoire et le CPU si la comptabilité est activée. Activez d'abord la comptabilité si nécessaire avec systemctl set-property ou en modifiant l'unité, mais notez qu'elle peut être désactivée par défaut sur certaines distributions.

systemctl show webapp -p MemoryCurrent -p CPUUsageNSec

Exemple de sortie :

MemoryCurrent=18446744073709551615
CPUUsageNSec=18446744073709551615

La valeur 18446744073709551615 est l'entier non signé 64 bits maximal, indiquant que la comptabilité n'est pas activée. Après avoir activé MemoryAccounting=yes et CPUAccounting=yes dans l'unité et rechargé, la même commande peut renvoyer :

MemoryCurrent=47923200
CPUUsageNSec=124000000

Cela signifie que le service utilise actuellement environ 45,7 Mio de mémoire et a consommé 0,124 seconde de temps CPU jusqu'à présent.

Documentez cette référence avant tout changement. Notez la date, la sortie exacte des commandes et les conditions de charge pertinentes (par exemple, « pendant le trafic de pointe avec 200 utilisateurs simultanés »). Cela vous donne une base de comparaison pour plus tard.

Chemin de configuration sécurisé

Une fois que vous connaissez l'état actuel, décidez de la limite à imposer. Le chemin le plus sûr est d'utiliser d'abord systemctl set-property au moment de l'exécution, car cela ne nécessite pas de redémarrer le service et peut être annulé instantanément. Cependant, les modifications au moment de l'exécution sont perdues au redémarrage, donc une fois la valeur confirmée, persistez-la dans un fichier de surcharge d'unité.

Modification au moment de l'exécution (non persistante)

Pour un service nommé webapp, limitez sa mémoire à 512 Mio et son CPU à 1,5 cœur :

sudo systemctl set-property webapp MemoryMax=512M CPUQuota=150%

Le pourcentage CPUQuota est relatif à un seul cœur : 150 % signifie 1,5 cœur de temps CPU. Après avoir exécuté cela, vérifiez la propriété :

systemctl show webapp -p MemoryMax -p CPUQuota

Sortie attendue :

MemoryMax=536870912
CPUQuota=150%

Notez que MemoryMax est affiché en octets. Le service est maintenant plafonné à 512 Mio de mémoire et à 1,5 cœur CPU.

Modification persistante via une surcharge

Pour rendre le changement permanent, créez un fichier de surcharge. Commencez par créer le répertoire s'il n'existe pas :

sudo mkdir -p /etc/systemd/system/webapp.service.d/

Créez ensuite un fichier nommé limits.conf dans ce répertoire :

[Service]
MemoryMax=512M
CPUQuota=150%
TasksMax=256

De manière équivalente, vous pouvez exécuter :

sudo systemctl edit webapp

Cela ouvre un éditeur pour un nouveau fichier de redéfinition. Ajoutez les trois mêmes lignes, enregistrez et quittez. Rechargez ensuite systemd et redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart webapp

Après le redémarrage, vérifiez à nouveau avec systemctl show webapp -p MemoryMax -p CPUQuota -p TasksMax. Les limites doivent maintenant être actives et survivre aux redémarrages.

Choix des valeurs limites

La partie la plus difficile de la planification de capacité est de sélectionner des nombres qui empêchent l'épuisement des ressources sans affamer le service. Un bon point de départ est d'exécuter le service sous une charge réaliste et d'observer son utilisation maximale. Supposons que vous puissiez déclencher un test de charge qui imite votre heure la plus chargée. Avec la comptabilité activée, enregistrez les pics de mémoire et de CPU sur plusieurs exécutions. Si vous constatez un pic de mémoire autour de 380 Mio, définir MemoryMax=512M offre une marge confortable. Si le pic de CPU est de 1,2 cœur, CPUQuota=150 % laisse de la place pour les pointes.

Fixez toujours des limites au-dessus des pics observés avec une marge de sécurité, et surveillez les étranglements ou les tueries OOM sous la même charge après application des limites.

Vérification et diagnostic

Après avoir appliqué une limite, vérifiez non seulement que la propriété est définie, mais aussi qu'elle est appliquée. systemd expose l'utilisation actuelle et les compteurs d'étranglement.

Vérifier l'utilisation actuelle de la mémoire et la limite

systemctl show webapp -p MemoryCurrent -p MemoryMax

Exemple :

MemoryCurrent=234881024
MemoryMax=536870912

Ici, le service utilise environ 224 Mio, sous le plafond de 512 Mio. Si MemoryCurrent est égal ou proche de MemoryMax, le service peut être sur le point d'atteindre la limite.

Vérifier l'étranglement du CPU

Lorsqu'un service dépasse son CPUQuota, le noyau l'étrangle. systemd suit le nombre d'événements d'étranglement et le temps total étranglé.

systemctl show webapp -p CPUThrottling

Sortie possible :

CPUThrottling=yes

Si un étranglement s'est produit, les propriétés suivantes sont non nulles :

systemctl show webapp -p CPUUsageNSec -p CPUTimeNSec -p CPUThrottledNSec -p CPUThrottledUSec

Exemple :

CPUUsageNSec=1240000000
CPUTimeNSec=1500000000
CPUThrottledNSec=260000000
CPUThrottledUSec=260000

Cela signifie que le service aurait utilisé 1,5 seconde de CPU, mais 0,26 seconde a été étranglée.

Vérifier les tueries OOM causées par MemoryMax

Si un service essaie d'allouer plus de mémoire que MemoryMax, le tueur OOM du noyau peut tuer un processus dans le cgroup. Vérifiez le journal :

journalctl -u webapp --since "10 minutes ago" | grep -i "out of memory"

Ou regardez le fichier memory.events du cgroup. Ce chemin dépend de la version du cgroup et de la hiérarchie. Sur cgroup v2 sous systemd, vous pouvez trouver le chemin du cgroup avec :

systemctl show webapp -p ControlGroup

Examinez ensuite /sys/fs/cgroup/<chemin>/memory.events. Le fichier rapporte les compteurs oom et oom_kill. Un oom_kill non nul signifie que la limite était trop basse.

Modes de défaillance et récupération

Les limites de capacité peuvent causer des défaillances subtiles. Les plus courantes sont les plantages de service dus aux limites de mémoire, la lenteur inexpliquée due à l'étranglement du CPU et les échecs de démarrage dus à une syntaxe de fichier d'unité invalide. Sachez reconnaître chacun et récupérer rapidement.

Service tué par la limite de mémoire

Symptôme : le service redémarre fréquemment, et systemctl status webapp affiche Main process exited, code=killed, status=9/KILL. Parfois, le statut affiche status=137/SIGKILL ou un message OOM.

Diagnostic : vérifiez journalctl -u webapp -e pour les lignes contenant Memory cgroup out of memory ou oom-kill.

Récupération : augmentez temporairement MemoryMax pour débloquer le service, puis étudiez le modèle d'utilisation réelle de la mémoire. Pour une augmentation rapide au moment de l'exécution :

sudo systemctl set-property webapp MemoryMax=1G

Décidez ensuite de rendre cela permanent et si l'application a une fuite de mémoire nécessitant une correction du code.

Étranglement du CPU causant une latence élevée

Symptôme : les temps de réponse de l'application augmentent considérablement sous charge, mais le CPU hôte n'est pas saturé. Le service peut afficher CPUThrottling=yes.

Diagnostic : vérifiez systemctl show webapp -p CPUThrottledNSec au fil du temps. Si le temps étranglé augmente pendant la charge, le quota est trop bas.

Récupération : augmentez CPUQuota par petites étapes. Par exemple, passez de 150 % à 200 % :

sudo systemctl set-property webapp CPUQuota=200%

Observez la latence et les métriques d'étranglement pendant quelques minutes. Si la latence récupère et que l'étranglement tombe à zéro, vous avez trouvé le problème. Sinon, considérez d'autres goulots d'étranglement.

Erreur de syntaxe du fichier d'unité empêchant le démarrage

Symptôme : après avoir modifié une surcharge et exécuté systemctl restart webapp, le service ne démarre pas, et systemctl status webapp affiche une erreur comme Failed to parse resource value, ignoring: abc ou Invalid argument.

Diagnostic : exécutez systemd-analyze verify /etc/systemd/system/webapp.service.d/limits.conf pour vérifier les erreurs de syntaxe. Ou exécutez systemctl daemon-reload, qui imprime souvent la ligne fautive.

Récupération : commentez ou supprimez la ligne problématique dans la surcharge, enregistrez et exécutez à nouveau systemctl daemon-reload. Une fois le service démarré, corrigez la valeur. Testez toujours les changements dans un environnement de préproduction si possible.

Oublier de recharger après modification de l'unité

Symptôme : vous modifiez un fichier d'unité, mais le service affiche toujours les anciennes valeurs de propriété après le redémarrage.

Diagnostic : comparez systemctl cat webapp avec systemctl show webapp -p MemoryMax. S'ils diffèrent, systemd n'a pas rechargé les définitions d'unité.

Récupération : exécutez sudo systemctl daemon-reload, puis redémarrez le service à nouveau. Prenez l'habitude d'exécuter daemon-reload après chaque modification de fichier d'unité.

Pièges courants

Même les opérateurs expérimentés font des erreurs. Voici les pièges fréquents dans la planification de capacité systemd et comment les éviter.

Définir des limites basées sur l'utilisation moyenne au lieu du pic

Pourquoi cela arrive : les tableaux de bord de surveillance montrent souvent la moyenne du CPU et de la mémoire sur de longues périodes, ce qui masque les pics. Un service qui utilise en moyenne 200 Mio peut atteindre 800 Mio lors d'un traitement par lots quotidien.

Comment l'éviter : collectez les métriques de pic à l'aide d'outils comme cAdvisor, systemd-cgtop ou des exportateurs Prometheus avec des métriques cgroup. Définissez des limites au-dessus du 95e ou 99e percentile des pics observés, et incluez une marge de sécurité.

Ne pas activer la comptabilité avant de se fier aux métriques

Pourquoi cela arrive : de nombreux tutoriels montrent la sortie de systemctl show avec l'utilisation actuelle, mais sur certaines distributions, la comptabilité de mémoire et de CPU est désactivée par défaut. Le service semble utiliser 18 exaoctets, ce qui est la valeur sentinelle pour « non comptabilisé ».

Comment l'éviter : définissez explicitement MemoryAccounting=yes, CPUAccounting=yes et TasksAccounting=yes dans une surcharge pour chaque service que vous devez mesurer. Rechargez et redémarrez, puis vérifiez que MemoryCurrent est un nombre raisonnable.

Appliquer des modifications au moment de l'exécution et supposer qu'elles persistent

Pourquoi cela arrive : systemctl set-property est rapide et réversible, il est donc tentant de l'utiliser en production et de l'oublier. Après un redémarrage, le service revient au fichier d'unité d'origine.

Comment l'éviter : traitez les modifications au moment de l'exécution comme temporaires. Après avoir confirmé qu'une valeur fonctionne, créez immédiatement une surcharge permanente avec les mêmes paramètres et testez un redémarrage.

Utiliser des contraintes absolues sans marge

Pourquoi cela arrive : les équipes veulent être strictes pour empêcher les services incontrôlables, mais définir MemoryMax exactement au pic observé ne laisse aucune marge pour de petites variations. Le service est tué par OOM de manière intermittente.

Comment l'éviter : ajoutez au moins 20 à 30 % de marge au-dessus du pic observé pour la mémoire. Pour le CPU, autorisez les pointes en fixant le quota plus haut que la moyenne mais en dessous du nombre total de cœurs de l'hôte.

Ignorer les différences de version de cgroup

Pourquoi cela arrive : certains contrôles de ressources, comme MemorySwapMax, se comportent différemment ou sont indisponibles sur cgroup v2. Les anciens guides peuvent faire référence à des chemins cgroup v1.

Comment l'éviter : vérifiez la version de cgroup avant de suivre un tutoriel. Utilisez les interfaces fournies par systemd (commandes systemctl et directives de fichier d'unité) au lieu d'écrire manuellement dans les fichiers cgroup, car systemd abstrait de nombreuses différences.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après avoir effectué des changements de capacité. Chaque élément nomme un propriétaire spécifique (une personne, pas un groupe) et une fréquence d'examen.

• [ ] Référence capturée : enregistrez la mémoire, le CPU et le nombre de tâches sous charge typique. Propriétaire : Priya Shah, responsable ingénierie. Examiner trimestriellement ou chaque fois que le profil de charge du service change.
• [ ] Comptabilité activée : vérifiez MemoryAccounting=yes et CPUAccounting=yes dans l'unité. Propriétaire : Alex Chen, ingénieur DevOps. Examiner après toute mise à niveau du système d'exploitation ou reconstruction d'image.
• [ ] Limites cibles définies avec marge : par exemple, MemoryMax=512M, CPUQuota=150 % basé sur le pic mesuré plus 25 % de marge. Propriétaire : Priya Shah. Examiner mensuellement.
• [ ] Test au moment de l'exécution effectué : utilisez systemctl set-property et observez pendant au moins un cycle de charge complet. Propriétaire : Alex Chen. Examiner avant chaque déploiement persistant.
• [ ] Fichier de surcharge créé et examiné : fichier placé dans /etc/systemd/system/<service>.service.d/limits.conf. Propriétaire : Alex Chen. Examiner immédiatement après la création.
• [ ] daemon-reload et redémarrage terminés : service redémarré sans erreurs. Propriétaire : Alex Chen. Vérifier dans chaque fenêtre de changement.
• [ ] Vérification post-changement : exécutez les vérifications systemctl show et journalctl ; confirmez qu'il n'y a pas de tueries OOM ni d'étranglement. Propriétaire : Priya Shah. Examiner après chaque changement.
• [ ] Plan de retour en arrière documenté : commandes pour annuler la surcharge et revenir aux limites précédentes. Propriétaire : Priya Shah. Examiner avant chaque changement.
• [ ] Alerte de surveillance définie : alerte lorsque l'utilisation de la mémoire du service dépasse 85 % de MemoryMax ou lorsque CPUThrottling=yes pendant plus de 5 minutes. Propriétaire : Alex Chen. Examiner mensuellement.

Conclusion

La planification de capacité avec systemd est une pratique opérationnelle continue, pas une tâche de configuration ponctuelle. En mesurant l'utilisation actuelle, en appliquant des limites via un chemin sécurisé, en vérifiant l'application et en vous préparant aux défaillances courantes, vous pouvez maintenir la stabilité des services et prévenir la contention des ressources sur les hôtes partagés.

Les techniques présentées ici s'appliquent à tout service géré par systemd, qu'il s'agisse d'une application web personnalisée, d'une base de données ou d'un worker en arrière-plan. Commencez par une limite à faible risque sur un service non critique, suivez la liste de contrôle et gagnez en confiance avant de déployer en production.

Rappelez-vous que chaque limite est une contrainte : trop élevée et elle ne protège rien, trop basse et elle casse le service. L'examen régulier des métriques et des limites, avec une propriété claire, garantit que votre planification de capacité suit l'évolution des charges de travail.