Supervision de SystemD avec systemd-cgtop

I. Présentation

Depuis quelques versions et releases les distributions Linux ont adopté SystemD. Cela permet de gérer au mieux les processus exécutés au sein duy système. Mais, ce que l'on sait moins, c'est que l'utilitaire systemd fournit de nombreuses commandes dont une particulièrement permettant la supervision de l'activité des processus ainsi que leur occupation en ressources: CPU et mémoire. Je vous propose dans ce tutoriel de décrire rapidement les fonctionnalités et les possibilités de la commande systemd-cgtop, équivalent à la commande universelle top permettant de suivre les processus.

II. Introduction aux cgroups

Les Control Groups (abrégés en cgroups), est une des nouveautés du noyau linux depuis la version CentOS7, permettant de limiter, comptabiliser et isoler éventuellement, l’utilisation des ressources du système : processeur, mémoire et disque.

Au début de ce projet, on parlait essentiellement de "conteneur de processus". Mais, dès 2007, le projet a été baptisé Control Groups et intégré au noyau linux 2.6.24. Depuis, de nombreux contrôleurs et nouveautés ont été ajoutés.

L’un des objectifs des cgroups est de fournir une interface unifiée pour les différents cas d’utilisation, du contrôle de processus au travers des mécanismes de priorité (avec nice), à la virtualisation du système d’exploitation (avec LXC, OpenVZ…). Ainsi, les cgroups permettent :

• La limitation de ressources: les groupes peuvent être mis en place afin de ne pas dépasser le seuil de la capacité de mémoire (en incluant le cache du système).
• La priorisation de ressources: certains groupes peuvent obtenir un plus grand quota de la capacité du processeur ou de la bande passante d’entrée-sortie.
• La comptabilisation de ressources: certaines commandes permettent de mesurer l’occupation des ressources consommées par certains systèmes.
• L’isolation de ressources: permet la séparation en espace de nommage pour les groupes afin qu’ils ne puissent pas interagir avec les processus des autres groupes, ni avec leurs connexions réseau ou leurs fichiers.
• Le contrôle de ressource: afin de figer les groupes et créer un point de reprise et permettre le redémarrage en cas de problème.

REMARQUE : les cgroups permettent de contrôler les processus d’une façon beaucoup plus complète et détaillée que les niveaux de priorité gérés avec la commande nice.

L’utilisation de contrôle n’est rien d’autre qu’une suite de processus liés par un même critère. Ces groupes peuvent ainsi organisés hiérarchiquement de façon que chacun hérite de son groupe parent. Le noyau linux fournit l’accès à plusieurs contrôleurs (que l’on peut considérer comme des sous-systèmes) à travers l’interface cgroup.

En effet, il est possible d’associer un ou plusieurs contrôleurs à un même cgroup :

• cpuset pour l’allocation de ressources CPU et mémoire
• cpuacct pour comptabiliser la consommation de cycle CPU
• memory pour contrôler la mémoire vive et le cache d’un groupe
• devices pour autoriser ou refuser l’accès à un périphérique
• net_cls pour gérer l’accès au réseau
• blkio pour gérer l’accès aux périphériques de type bloc

Les Control Groups peuvent être utilisés de multiples façons :

• en accédant au système de fichier virtuel cgroup manuellement via la commande mount
• en créant et administrant des groupes à la volée en utilisant les commandes cgcreate, cgexec, cgclassify de la bibliothèque libcgroup.
• via le daemon du moteur de règles pouvant automatiquement déplacer les processus de certains utilisateurs, groupes ou commandes vers un cgroup en respectant la configuration souhaitée.
• indirectement, à travers d’autres utilitaires utilisant eux-mêmes les cgroups comme LXC, SystemD ou libvirt.

Comme pour tout système, il est possible également de superviser l’activité de SystemD, grâce à la commande systemd-cgtop.

Exemple : affichage systemd-cgtop

III. La commande systemd-cgtop

Cette commande permet de présenter les groupes de contrôle au sommet de la hiérarchie des contrôles locaux du système de façon ordonnée selon un des champs : CPU, mémoire, ou entrées/sorties disque. L’affichage est rafraichi à intervalles réguliers (par défaut toutes les secondes). Le fonctionnement est approximativement le même que pour la commande top des processus système.

REMARQUE : si la commande systemd-cgtop n’est pas associée à un terminal tty, aucun entête de colonne ne s’affichera et une seule itération sera exécutée. On a alors la possibilité de mentionner l’option --iterations= pour préciser le nombre de boucle à exécuter.

La commande possède de nombreuses options, permettant de fournir le paramètre d’accès (aussi appelé path) au groupe de contrôle, le n° de tâche ou de processus, la charge CPU, l’utilisation mémoire ou celle des disques via ses entrées/sorties. Voici un récapitulatif des différentes options possibles :

Lorsque l’on souhaite connaître à quelle hiérarchie appartient un groupe de contrôle, il suffit d’utiliser la commande systemd-cgls pour afficher l’arbre complet de la hiérarchie du système trié par groupe de contrôles.

Cette commande affiche de façon récursive le contenu hiérarchique des groupes de contrôle du système au sein d’une arborescence. Elle met en évidence les processus par cgroup et leur service associé. En effet, pour rappel le service systemd principal nomme les groupes de contrôle d’après les services.

REMARQUE : il existe aussi la commande systemd-delta permettant d’identifier et comparer les fichiers de configuration du répertoire /etc ayant leur correspondance par défaut dans le dossier /usr :

On peut également interroger le système via la commande traditionnelle ps en utilisant les options suivantes :

$ ps xawf -eo pid,user,cgroups,args

Cela permet alors de lister les processus avec le n° PID, l’utilisateur associé, le cgroup d’appartenance et les arguments du processus sous la forme suivante :

IV. Conclusion

Voilà un bref aperçu de la puissance de SystemD et des groupes de contrôle. On voit ainsi les possibilités d’optimisation des processus en les ordonnançant de façon minimaliste. Par ailleurs, cela permet également de superviser les processus et de déterminer le cas échéant ceux qui déborde ou utilise les ressources du système de façon incohérente. Et je dois reconnaître, même si au début je n’étais pas un partisan de SystemD, que je suis plutôt agréablement surpris de sa capacité à révéler les coulisses du système et à faciliter la vie des administrateurs.

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

See Full Bio