LFCS : surveiller l'utilisation des ressources des processus Linux et définir les limites des processus par utilisateur - Partie 14
En raison de récentes modifications apportées aux objectifs de l'examen de certification LFCS, entrées en vigueur le 2 février 2016, nous ajoutons les articles nécessaires à la série LFCS publiée ici. Pour vous préparer à cet examen, vous êtes fortement encouragés à passer également par la série LFCE.
Chaque administrateur système Linux doit savoir comment vérifier l'intégrité et la disponibilité du matériel, des ressources et des processus clés. En outre, la définition de limites de ressources par utilisateur doit également faire partie de ses compétences.
Dans cet article, nous explorerons quelques façons de garantir que le système, tant matériel que logiciel, se comporte correctement afin d'éviter des problèmes potentiels pouvant entraîner des arrêts de production inattendus et des pertes d'argent.
Statistiques des processeurs de reporting Linux
Avec mpstat, vous pouvez visualiser les activités de chaque processeur individuellement ou du système dans son ensemble, à la fois sous forme d'instantané unique ou de manière dynamique.
Pour utiliser cet outil, vous devrez installer sysstat :
yum update && yum install sysstat [On CentOS based systems]
aptitutde update && aptitude install sysstat [On Ubuntu based systems]
zypper update && zypper install sysstat [On openSUSE systems]
En savoir plus sur sysstat et ses utilitaires sur Learn Sysstat et ses utilitaires mpstat, pidstat, iostat et sar sous Linux
Une fois que vous avez installé mpstat, utilisez-le pour générer des rapports sur les statistiques des processeurs.
Pour afficher 3 rapports globaux sur l'utilisation du processeur (-u) pour tous les processeurs (comme indiqué par -P ALL) à un intervalle de 2 secondes , faire:
mpstat -P ALL -u 2 3
Exemple de sortie
Linux 3.19.0-32-generic (linux-console.net) Wednesday 30 March 2016 _x86_64_ (4 CPU)
11:41:07 IST CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11:41:09 IST all 5.85 0.00 1.12 0.12 0.00 0.00 0.00 0.00 0.00 92.91
11:41:09 IST 0 4.48 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 94.53
11:41:09 IST 1 2.50 0.00 0.50 0.00 0.00 0.00 0.00 0.00 0.00 97.00
11:41:09 IST 2 6.44 0.00 0.99 0.00 0.00 0.00 0.00 0.00 0.00 92.57
11:41:09 IST 3 10.45 0.00 1.99 0.00 0.00 0.00 0.00 0.00 0.00 87.56
11:41:09 IST CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11:41:11 IST all 11.60 0.12 1.12 0.50 0.00 0.00 0.00 0.00 0.00 86.66
11:41:11 IST 0 10.50 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 88.50
11:41:11 IST 1 14.36 0.00 1.49 2.48 0.00 0.00 0.00 0.00 0.00 81.68
11:41:11 IST 2 2.00 0.50 1.00 0.00 0.00 0.00 0.00 0.00 0.00 96.50
11:41:11 IST 3 19.40 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 79.60
11:41:11 IST CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11:41:13 IST all 5.69 0.00 1.24 0.00 0.00 0.00 0.00 0.00 0.00 93.07
11:41:13 IST 0 2.97 0.00 1.49 0.00 0.00 0.00 0.00 0.00 0.00 95.54
11:41:13 IST 1 10.78 0.00 1.47 0.00 0.00 0.00 0.00 0.00 0.00 87.75
11:41:13 IST 2 2.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 97.00
11:41:13 IST 3 6.93 0.00 0.50 0.00 0.00 0.00 0.00 0.00 0.00 92.57
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 7.71 0.04 1.16 0.21 0.00 0.00 0.00 0.00 0.00 90.89
Average: 0 5.97 0.00 1.16 0.00 0.00 0.00 0.00 0.00 0.00 92.87
Average: 1 9.24 0.00 1.16 0.83 0.00 0.00 0.00 0.00 0.00 88.78
Average: 2 3.49 0.17 1.00 0.00 0.00 0.00 0.00 0.00 0.00 95.35
Average: 3 12.25 0.00 1.16 0.00 0.00 0.00 0.00 0.00 0.00 86.59
Pour afficher les mêmes statistiques pour un CPU spécifique (CPU 0 dans l'exemple suivant), utilisez :
mpstat -P 0 -u 2 3
Exemple de sortie
Linux 3.19.0-32-generic (linux-console.net) Wednesday 30 March 2016 _x86_64_ (4 CPU)
11:42:08 IST CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11:42:10 IST 0 3.00 0.00 0.50 0.00 0.00 0.00 0.00 0.00 0.00 96.50
11:42:12 IST 0 4.08 0.00 0.00 2.55 0.00 0.00 0.00 0.00 0.00 93.37
11:42:14 IST 0 9.74 0.00 0.51 0.00 0.00 0.00 0.00 0.00 0.00 89.74
Average: 0 5.58 0.00 0.34 0.85 0.00 0.00 0.00 0.00 0.00 93.23
Le résultat des commandes ci-dessus affiche ces colonnes :
CPU: numéro de processeur sous forme d'entier, ou le mot all sous forme de moyenne pour tous les processeurs.%usr: pourcentage d'utilisation du processeur lors de l'exécution d'applications au niveau utilisateur.%nice: identique à%usr, mais avec une belle priorité.%sys: pourcentage d'utilisation du processeur lors de l'exécution des applications du noyau. Cela n'inclut pas le temps passé à gérer les interruptions ou à gérer le matériel.%iowait: pourcentage de temps pendant lequel le processeur donné (ou la totalité) était inactif, pendant lequel une opération d'E/S gourmande en ressources a été planifiée sur ce processeur. Une explication plus détaillée (avec des exemples) peut être trouvée ici.%irq: pourcentage de temps passé à traiter les interruptions matérielles.%soft: identique à%irq, mais avec des interruptions logicielles.%steal: Pourcentage de temps passé en attente involontaire (vol ou temps volé) lorsqu'une machine virtuelle, en tant qu'invitée, « gagne » l'attention de l'hyperviseur tout en rivalisant pour le(s) processeur(s). Cette valeur doit rester aussi petite que possible. Une valeur élevée dans ce champ signifie que la machine virtuelle est au point mort – ou le sera bientôt.%guest: Pourcentage de temps passé à exécuter un processeur virtuel.%idle: pourcentage de temps pendant lequel le(s) processeur(s) n'exécutaient aucune tâche. Si vous observez une valeur faible dans cette colonne, cela indique que le système est soumis à une forte charge. Dans ce cas, vous devrez examiner de plus près la liste des processus, comme nous le verrons dans une minute, pour déterminer la cause.
Pour placer le processeur sous une charge quelque peu élevée, exécutez les commandes suivantes, puis exécutez mpstat (comme indiqué) dans un terminal séparé :
dd if=/dev/zero of=test.iso bs=1G count=1
mpstat -u -P 0 2 3
ping -f localhost # Interrupt with Ctrl + C after mpstat below completes
mpstat -u -P 0 2 3
Enfin, comparez avec le résultat de mpstat dans des circonstances « normales » :
Comme vous pouvez le voir dans l'image ci-dessus, le CPU 0 était soumis à une forte charge lors des deux premiers exemples, comme l'indique la colonne %idle.
Dans la section suivante, nous verrons comment identifier ces processus gourmands en ressources, comment obtenir plus d'informations à leur sujet et comment prendre les mesures appropriées.
Rapports sur les processus Linux
Pour lister les processus en les triant par utilisation du processeur, nous utiliserons la commande bien connue ps avec le -eo (pour sélectionner tous les processus avec un format défini par l'utilisateur) et --sort (pour spécifier un ordre de tri personnalisé), comme ceci :
ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu
La commande ci-dessus affichera uniquement le PID, le PPID, la commande associée au processus et le pourcentage d'utilisation du processeur et de la RAM triés par pourcentage d'utilisation du processeur par ordre décroissant. . Lorsqu'il est exécuté lors de la création du fichier .iso, voici les premières lignes du résultat :
Une fois que nous avons identifié un processus intéressant (comme celui avec PID=2822), nous pouvons accéder à /proc/PID (/proc/2822 dans ce cas) et faites une liste de répertoires.
Ce répertoire est l'endroit où plusieurs fichiers et sous-répertoires contenant des informations détaillées sur ce processus particulier sont conservés pendant son exécution.
Par exemple:
/proc/2822/iocontient les statistiques d'E/S du processus (nombre de caractères et d'octets lus et écrits, entre autres, lors des opérations d'E/S)./proc/2822/attr/currentaffiche les attributs de sécurité SELinux actuels du processus./proc/2822/cgroupdécrit les groupes de contrôle (cgroups en abrégé) auxquels appartient le processus si l'option de configuration du noyau CONFIG_CGROUPS est activée, ce que vous pouvez vérifier avec :
cat /boot/config-$(uname -r) | grep -i cgroups
Si l'option est activée, vous devriez voir :
CONFIG_CGROUPS=y
À l'aide de cgroups, vous pouvez gérer la quantité d'utilisation des ressources autorisée par processus, comme expliqué dans les chapitres 1 à 4 du guide de gestion des ressources Red Hat Enterprise Linux 7, au chapitre 9 de l'analyse du système openSUSE. et de réglage, ainsi que dans la section Groupes de contrôle de la documentation du serveur Ubuntu 14.04.
Le /proc/2822/fd est un répertoire qui contient un lien symbolique pour chaque descripteur de fichier ouvert par le processus. L'image suivante montre ces informations pour le processus qui a été démarré dans tty1 (le premier terminal) pour créer l'image .iso :
L'image ci-dessus montre que stdin (descripteur de fichier 0), stdout (descripteur de fichier 1) et stderr (descripteur de fichier 2) sont mappés sur /dev/zero, /root/test.iso et /dev/tty1, respectivement.
Plus d'informations sur /proc peuvent être trouvées dans le document « Le système de fichiers /proc » conservé et maintenu par Kernel.org, et dans le manuel du programmeur Linux.
Définition des limites de ressources par utilisateur sous Linux
Si vous ne faites pas attention et autorisez n'importe quel utilisateur à exécuter un nombre illimité de processus, vous risquez éventuellement de subir un arrêt inattendu du système ou d'être verrouillé lorsque le système entre dans un état inutilisable. Pour éviter que cela ne se produise, vous devez limiter le nombre de processus que les utilisateurs peuvent démarrer.
Pour ce faire, éditez /etc/security/limits.conf et ajoutez la ligne suivante en bas du fichier pour définir la limite :
* hard nproc 10
Le premier champ peut être utilisé pour indiquer soit un utilisateur, soit un groupe, soit tous (*), tandis que le deuxième champ impose une limite stricte au nombre de processus (nproc) à 10. Pour appliquer les modifications, il suffit de se déconnecter puis de se reconnecter.
Voyons donc ce qui se passe si un certain utilisateur autre que root (qu'il soit légitime ou non) tente de lancer une bombe à fourche. Si nous n'avions pas implémenté de limites, cela lancerait dans un premier temps deux instances d'une fonction, puis dupliquerait chacune d'elles dans une boucle sans fin. Ainsi, cela finirait par amener votre système à une exploration.
Cependant, avec la restriction ci-dessus en place, la bombe fork ne réussit pas mais l'utilisateur sera toujours verrouillé jusqu'à ce que l'administrateur système tue le processus qui lui est associé :
CONSEIL : D'autres restrictions possibles rendues possibles par ulimit sont documentées dans le fichier limits.conf.
Linux Autres outils de gestion de processus
En plus des outils évoqués précédemment, un administrateur système peut également devoir :
a) Modifier la priorité d'exécution (utilisation des ressources système) d'un processus à l'aide de renice. Cela signifie que le noyau allouera plus ou moins de ressources système au processus en fonction de la priorité assignée (un nombre communément appelé « gentilesse » compris entre -20 et 19).
Plus la valeur est faible, plus la priorité d'exécution est élevée. Les utilisateurs réguliers (autres que root) ne peuvent modifier la qualité des processus qu'ils possèdent qu'à une valeur plus élevée (ce qui signifie une priorité d'exécution inférieure), tandis que root peut modifier cette valeur pour n'importe quel processus et peut l'augmenter ou la diminuer.
La syntaxe de base de renice est la suivante :
renice [-n] <new priority> <UID, GID, PGID, or empty> identifier
Si l'argument après la nouvelle valeur de priorité n'est pas présent (vide), il est défini sur PID par défaut. Dans ce cas, la qualité du processus avec PID=identifier est définie sur
b) Interrompre l'exécution normale d'un processus lorsque cela est nécessaire. C’est ce qu’on appelle communément « tuer » le processus. Sous le capot, cela signifie envoyer au processus un signal pour terminer son exécution correctement et libérer toutes les ressources utilisées de manière ordonnée.
Pour arrêter un processus, utilisez la commande kill comme suit :
kill PID
Alternativement, vous pouvez utiliser pkill pour terminer tous les processus d'un propriétaire donné (-u), ou d'un propriétaire de groupe (-G), ou même les processus qui ont un PPID. en commun (-P). Ces options peuvent être suivies de la représentation numérique ou du nom réel comme identifiant :
pkill [options] identifier
Par exemple,
pkill -G 1000
tuera tous les processus appartenant au groupe avec GID=1000.
Et,
pkill -P 4993
tuera tous les processus dont le PPID est 4993.
Avant d'exécuter un pkill, c'est une bonne idée de tester d'abord les résultats avec pgrep, peut-être en utilisant également l'option -l pour lister les noms des processus. Il prend les mêmes options mais renvoie uniquement les PID des processus (sans entreprendre aucune autre action) qui seraient tués si pkill était utilisé.
pgrep -l -u gacanepa
Ceci est illustré dans l’image suivante :
Résumé
Dans cet article, nous avons exploré quelques façons de surveiller l'utilisation des ressources afin de vérifier l'intégrité et la disponibilité des composants matériels et logiciels critiques dans un système Linux.
Nous avons également appris comment prendre les mesures appropriées (soit en ajustant la priorité d'exécution d'un processus donné, soit en y mettant fin) dans des circonstances inhabituelles.
Nous espérons que les concepts expliqués dans ce didacticiel vous ont été utiles. Si vous avez des questions ou des commentaires, n'hésitez pas à nous contacter en utilisant le formulaire de contact ci-dessous.