Comment limiter l'utilisation du processeur et de la RAM d'un processus avec les cgroups sous Ubuntu

Sous Ubuntu, la méthode la plus sûre pour limiter la charge de travail avec les cgroups consiste à laisser systemd créer et gérer son groupe de contrôle. Utilisez cette systemd-runméthode pour une commande que vous lancez, ou configurez un service systemd lorsque la limite doit persister après un redémarrage. Définissez CPUQuota=une limite stricte de temps CPU et choisissez entre MemoryHigh=une limite de pression et MemoryMax=une limite de mémoire. Ces limites s'appliquent à l'unité et à ses processus enfants.

Un cgroup (groupe de contrôle) est un mécanisme du noyau Linux qui organise les processus afin que le système puisse comptabiliser et contrôler leur utilisation des ressources. Sous Ubuntu, systemd place déjà les services dans des cgroups ; la plupart des utilisateurs n'ont donc pas besoin de créer manuellement de répertoires /sys/fs/cgroup. Les exemples ci-dessous utilisent l'interface de contrôle des ressources de systemd et doivent être vérifiés avec la version de systemd installée sur votre distribution Ubuntu.

Choisissez la commande qui correspond au problème

Pour la plupart des machines Ubuntu interactives, une portée transitoire est l'option la plus rapide et réversible. Pour un service en production, utilisez l'unité de service afin que la politique soit documentée et restaurée au démarrage. N'utilisez les fichiers cgroup directement que si vous gérez délibérément une hiérarchie déléguée ou si vous créez un flux de travail conteneur/d'exécution.

Vérifiez le système Ubuntu avant de définir des limites

Vérifiez d'abord que systemd est disponible et si le système de fichiers cgroup est unified v2 :

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

Le résultat de cgroup2fsla seconde commande indique le système de fichiers cgroup v2 unifié. Les versions d'Ubuntu et les systèmes personnalisés peuvent différer ; ne présumez donc pas que chaque machine possède la même hiérarchie ou les mêmes fonctionnalités systemd. Vous pouvez également vérifier la version actuelle de systemd avec la première commande. Si le montage cgroup n'est pas en v2, certaines propriétés des ressources ou le comportement du contrôleur peuvent différer ; consultez la page de manuel d'Ubuntu correspondant à la version installée avant de copier une configuration.

Choisissez les valeurs après avoir mesuré la charge de travail. Prévoyez une marge pour le reste du système et n'oubliez pas que les limites définies pour un service utilisateur sont également soumises aux limites de son cgroup parent. Un cgroup enfant ne peut pas recevoir plus de ressources que son ancêtre ne le permet.

Limitez une commande que vous êtes sur le point de démarrer

Pour une commande de votre propre session utilisateur, lancez-la dans une portée transitoire avec systemd-run --user --scope. Par exemple :

systemd-run --user --scope --unit=worker-capped \
  -p CPUQuota=50% \
  -p MemoryHigh=700M \
  -p MemoryMax=900M \
  -- python3 /opt/worker.py

Remplacez la commande Python par le programme que vous souhaitez exécuter. Cet exemple attribue au cgroup une bande passante CPU maximale équivalente à la moitié d'un cœur de processeur, active la gestion de la pression mémoire autour de 700 Mio et fixe une limite de mémoire maximale de 900 Mio. Les valeurs de mémoire sont exprimées en unités de base 1024 de systemd. Un quota 100%représente le temps d'exécution d'un cœur de processeur ; 200%il peut utiliser jusqu'à deux cœurs si disponible. Il ne s'agit pas d'un pourcentage du nombre total de cœurs de l'ordinateur.

La commande s'exécute au premier plan car il s'agit d'une unité temporaire. À sa fermeture, l'unité temporaire disparaît. Ne la supprimez --userque si vous prévoyez d'utiliser le gestionnaire système et que vous disposez des privilèges requis ; pour une unité temporaire système, exécutez la commande avec sudoles options appropriées. Les paramètres de ressources peuvent être refusés si le gestionnaire ou le contrôleur cgroup ne les prend pas en charge.

Définir des limites pour un service systemd persistant

Pour un service tel que worker.service, créez un module complémentaire au lieu de modifier le fichier d'unité du fournisseur. Exécutez sudo systemctl edit worker.serviceet ajoutez :

[Service]
CPUQuota=50%
MemoryHigh=700M
MemoryMax=900M

Enregistrez le fichier de configuration, puis rechargez les définitions d'unités de systemd et redémarrez le service afin que le processus démarre selon la politique révisée :

sudo systemctl daemon-reload
sudo systemctl restart worker.service

Utilisez une limite de mémoire prudente. Si le service ne parvient pas à récupérer suffisamment de mémoire en dessous d'un certain seuil MemoryMax, le noyau peut déclencher le processus de gestion de la mémoire insuffisante au sein du cgroup. Cela peut interrompre un ou plusieurs processus du groupe de services et provoquer des interruptions. Il est souvent plus sûr de définir MemoryHighune limite de mémoire où la récupération et la limitation de débit sont acceptables, puis de la fixer MemoryMaxà un niveau supérieur comme limite finale. Effectuez des tests avec des pics de charge réalistes avant d'appliquer des limites strictes.

Vérifiez l'appareil et observez son comportement.

Pour l'oscilloscope transitoire, vérifiez son état en utilisant le nom d'unité que vous avez fourni :

systemctl --user status worker-capped.scope
systemd-cgtop

Pour un service système, omettez l'option correspondante --userdans la commande d'état. La vue d'état confirme l'existence et l'activité de l'unité ; systemd-cgtopelle affiche l'utilisation des ressources en temps réel par groupe de contrôle. Pour examiner les propriétés configurées, interrogez directement l'unité, par exemple :

systemctl --user show worker-capped.scope \
  -p CPUQuotaPerSecUSec -p MemoryHigh -p MemoryMax

La mémoire affichée pour un cgroup ne correspond pas nécessairement à la mémoire résidente d'un processus : elle prend en compte la mémoire allouée au groupe et peut inclure les processus descendants de la charge de travail. Il convient d'interpréter la surveillance comme un indicateur du comportement de cette charge de travail dans le temps, et non comme une valeur unique à optimiser aveuglément.

Que se passe-t-il si le processus est déjà en cours d'exécution ?

systemd-runCette commande lance une nouvelle unité ; elle ne déplace pas un PID existant arbitraire dans cette unité. Si le processus appartient à un service systemd, appliquez les paramètres à ce service via une commande spécifique ou, pour une modification temporaire, utilisez la commande appropriée sudo systemctl set-property --runtime worker.service CPUQuota=50% MemoryHigh=700M MemoryMax=900M. Cette --runtimedernière est temporaire et ne remplace pas la configuration permanente d'un service.

Si le processus est un programme régulier de votre session de bureau, la méthode la plus simple et la plus sûre consiste généralement à l'arrêter et à le relancer systemd-run. Appliquer une propriété à une zone plus large, comme votre espace utilisateur complet, peut affecter de nombreuses applications sans lien entre elles. Déplacer un processus en écrivant son PID dans un fichier cgroup nécessite de contrôler la hiérarchie déléguée correspondante et de respecter les règles de placement des processus cgroup v2 ; n'écrivez pas dans les répertoires gérés par systemd sans précaution.

Comment choisir une politique de processeur et de mémoire

• Besoin d'une limite de processeur stricte ? Choisissez l'option correspondante CPUQuota=. Des valeurs plus basses réduisent la consommation maximale du processeur, mais peuvent ralentir l'exécution et augmenter le temps d'attente.
• Besoin d'une priorité plus basse ? Privilégiez CPUWeight=plutôt qu'un quota. Le poids répartit la charge du processeur de manière proportionnelle à la charge ; il ne réserve pas un pourcentage fixe et n'empêche pas l'utilisation du processeur inactif.
• Besoin de pression sur la mémoire sans arrêt brutal immédiat ? Définissez MemoryHigh=-la comme seuil de pression principal et observez la latence et le comportement de récupération.
• Besoin d'une limite de confinement finale ? Prévoyez MemoryMax=une marge suffisante pour les pics normaux. Soyez prêt à gérer les situations de mémoire insuffisante (OOM) lorsque la limite ne peut être respectée.
• Vous utilisez déjà un conteneur ? Privilégiez les options de configuration du processeur et de la mémoire prises en charge par le gestionnaire de conteneurs, qui configurent les cgroups pour ce conteneur et s’adaptent à son cycle de vie.

Il n'existe pas de limite idéale unique pour toutes les charges de travail. Un traitement par lots sur un ordinateur de bureau peut tolérer un quota faible et une limite de mémoire modérée ; un service sensible à la latence peut nécessiter une plus grande marge de manœuvre du processeur et une limite plus élevée MemoryHighpour éviter les pauses liées à la récupération de mémoire. Commencez par des valeurs prudentes, surveillez l'unité pendant un pic représentatif et ajustez un paramètre à la fois.

Références

• Documentation Ubuntu : contrôle des ressources cgroups et systemd
• Page de manuel d'Ubuntu : systemd-run
• Page de manuel Ubuntu : systemd.resource-control
• Documentation du noyau Linux : Groupe de contrôle v2