Gestion des processus II

Comptabilité des processus

La comptabilité des processus vous permet de disposer d'informations détaillées sur les ressources système utilisées, sur leur répartition entre les utilisateurs, et, plus généralement, de surveiller le système. Pour l'utiliser voir Comment activer la comptabilité des processus sous Linux

Vous aurez besoin d'installer le paquetage 'psacct'. Un service système éponyme (autrement dit portant le même nom) sera installé en retour, comme vous pourrez le vérifier, par exemple, en regardant dans la rubrique 'Système -> Services' du Centre de Contrôle Mandriva. De la documentation (et un peu de folklore Unix) sera disponible via la commande info accounting. Les différentes commandes (acct, ac, accton, last, lastcomm, sa) possèdent une page de man (faire man acct etc.). Webmin et Linuxconf proposent des modules graphiques pour configurer et gérer la comptabilité des processus.

Index de la section Administration du système - Index de la Base de Connaissances

Estimation de l'utilisation des ressources par les processus

Estimer l'utilisation des ressources, en particulier la consommation mémoire des processus, est bien plus compliqué qu'il n'y paraît au premier abord.

La quantité de ressources dont un processus a besoin dépend de nombreux facteurs, dont la plupart sont variables. L'un d'entre eux est la quantité de mémoire vive physique (RAM) du système. Quand une importante quantité de RAM libre est disponible, davantage de mémoire est utilisé par le système de cache, et en conséquence plus de mémoire sera consommée. Cependant cela ne compte pas vraiment comme utilisation des ressources, puisque cette mémoire 'cache' est disponible si d'autres processus en ont besoin. Jusqu'à 20% de la mémoire système peut être utilisée en tampons et en caches. Cela améliore grandement les accès disque, donc vous ne 'perdez' rien lorsque la mémoire est assignée à cette tâche. Il n'y a que la mémoire non utilisée qui est gâchée ;-)

Les applications graphiques utilisent des bibliothèques de fonctions pour afficher leur interface (boutons, menus, etc.). Les bibliothèques les plus courantes sont GTK+ (GIMP, GNOME), Qt (KDE) et Tcl/Tk. Si vous utilisez des applications de différentes sortes, toutes les bibliothèques associées seront chargées en mémoire système, et donc utiliseront plus de ressources. Une application écrite avec Qt pour KDE utilisera plus de ressources dans GNOME que sous KDE. Cependant, si vous démarrez une deuxième application Qt, elle utilisera la même quantité de ressources que sous KDE car les bibliothèques d'interface auront déjà été chargées avec la première application. Si vous fermez les deux applications, toutes les ressources ne seront pas libérées immédiatement, les bibliothèques chargées resteront en cache (si la quantité de mémoire vive libre le permet).

Les valeurs présentées par les outils de surveillance pour chaque processus prêtent donc à confusion et sont facilement mal interprétées. À la page précédente, vous avez déjà appris quelque chose sur les threads. Mais même si le processus ne crée pas de threads, il est dans la plupart des cas impossible de savoir combien de mémoire système une application utilise vraiment.

Voyons cela sur un exemple, qui correspond aux lignes affichées par la commande 'top' :

Mem: 900040K total, 411864K used, 488176K free, 1048K shrd, 58592K buff, 166816K cac

• Lançons l'éditeur HTML 'bluefish'.

4716 (VIRT) 4716 (RES) 3580 (SHR)

Une deuxième exécution de 'top' donne maintenant ceci pour l'ensemble du système :

Mem: 900040K total, 414268K used, 485772K free, 1432K shrd, 58620K buff, 167592K cac

Selon l'entrée du tableau des processus, 'bluefish' utilise 4716 Ko de mémoire réelle (RES) et 3580 Ko de mémoire partagée (SHR). Le système n'indique cependant qu'une augmentation de 2404 Ko d'utilisation de mémoire, dont 400 Ko de plus en mémoire partagée, 30 Ko de plus en buffers (tampons) et 600 Ko de plus en cache.
De quelque façon que vous vous y preniez pour soustraire ou pour ajouter, vous ne vous y retrouverez pas.

En principe, je fais plutôt confiance aux chiffres du système, mais ils peuvent eux aussi être facilement mal interprétés. Voilà ce que vous pourriez avoir sur un autre système :

42 processes: 41 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.9% user, 1.3% system, 0.0% nice, 97.6% idle
Mem: 257676K total, 252940K used, 4736K free, 202852K shrd, 7464K buff
Swap: 130748K total, 256K used, 130492K free, 197620K cached

Ce qui embrouille les gens ici, c'est la gestion du cache et des tampons ('buffers' en anglais) sous Linux. Regardons cela de plus près :

Mem: 257676K total, 252940K used, 4736K free, 202852K shrd, 7464K buff
Swap: 130748K total, 256K used, 130492K free 197620K cached

'Mem' affiche pas loin de 252 Mo (257676/1024 = 251,6) de RAM disponible installée sur le système, alors qu'en fait ce système est doté de 256 Mo de RAM. Où sont passés les 4 Mo restant ?

C'est simple : ils sont utilisés pour le BIOS Shadowing (copie du BIOS en RAM) et ils contiennent aussi le noyau Linux.

Les champs suivants semblent indiquer que le système est sur le point de s'effondrer : presque toute la mémoire semble être utilisée. Est-ce vrai ? Non. Regardez les derniers chiffres de ces lignes. Ils vous indiquent qu'environ 200 Mo de mémoire système est utilisé par les tampons (les 'buffers') et le cache. Cette mémoire est en fait disponible pour toute application qui en aurait besoin.

La commande 'free' donne une image plus compréhensible :

$ free

             total      used    free    ...
Mem:        257676    253624    4052    ...
-/+ buffers/cache:     50360  207316
Swap:       130748       256  130492

Regardons la 3ème ligne :

-/+ buffers/cache:     50360  207316

Elle affiche à nouveau la véritable quantité de mémoire utilisée par les applications (50 Mo) et la mémoire libre (202 Mo). Le reste est utilisé pour le cache et les tampons, c'est-à-dire pour rendre votre système plus rapide.

Pour disposer d'une estimation de la consommation des ressources par un processus, il est plus facile d'exécuter la commande 'free', avant, pendant et après l'exécution d'un programme. Les chiffres varieront pour les raisons évoquées précédemment ; vous aurez donc à le faire plusieurs fois pour avoir une moyenne.

Index de la section Administration du système - Index de la Base de Connaissances

Limiter l'utilisation des ressources

PAM (Pluggable Authentication Modules, man 8 pam) offre un mécanisme pour limiter l'utilisation des ressources ; utiliser les mécanismes offerts par le shell ('ulimit' dans bash, 'limit' dans csh etc) est dépassé.
Vous configurez ces limites en tant que 'root' dans '/etc/security/limits.conf'. Entre autres, vous pouvez définir le nombre maximal de processus par utilisateur ou par groupe d'utilisateurs, les priorités des processus, le temps maximal de CPU, etc.
Les paramètres et des exemples sont fournis dans le fichier de configuration.

Davantage d'informations peuvent être trouvées dans le chapitre approprié de L-PAMSAG.

Index de la section Administration du système - Index de la Base de Connaissances

Comment en user avec les processus défaillants ou inutiles

Si un processus se comporte mal, le noyau lui envoie, pour l'arrêter, un signal approprié (vous en trouverez la liste dans man 7 signal).
Le signal le plus infamant de tous est le SIGNAL 11 (alias SIGSEGV, alias 'segmentation fault') : le processus a essayé d'accéder à un segment mémoire qui ne lui avait pas été alloué.
Les raisons de ce 'segfault' peuvent venir d'une erreur de programmation, de l'utilisation d'une mauvaise version de bibliothèque ou d'un problème matériel. L'action par défaut d'un processus qui reçoit ce signal est de se terminer et d'écrire le contenu de la mémoire systèmL dans un fichier appelé 'core' (en termes Unix, le processus 'dumpe sa mémoire'). Ce fichier 'core' peut être utile à un programmeur pour analyser le problème (faire du déboguage). Notez que Mandriva linux désactive par défaut la création des fichiers 'core'.

Les choses se compliquent lorsque le processus est un si mauvais sujet qu'il ignore ce signal et commence à accaparer toutes les ressources du processeur, ralentissant ainsi tous les autres processus. Le noyau marque ce processus comme 'non interruptible' et son statut dans la table des processus passe de 'R' (en cours d'exécution) ou 'S' (endormi) à 'D' (non interruptible et dormant). Si vous voyez l'état 'D' associé à un processus (par exemple grâce à la commande 'top'), il est vraiment temps de faire quelque chose.

Quasiment tous les signaux peuvent être gérés par les processus, ce qui veut dire qu'ils peuvent aussi être ignorés. Il y a néanmoins un signal qui ne peut pas être ignoré par un processus : le signal 9 (SIGKILL), le bien nommé 'signal de la mort'. Si vous envoyez ce signal à un processus, vous le terrasserez en lui supprimant ses ressources et en le retirant de la table des processus. Vous pouvez alors continuer paisiblement votre travail habituel. Les données non sauvegardées de ce processus seront perdues aussi.

La plupart des outils de surveillance du système vous permettent de tuer un processus en utilisant le bouton droit de la souris (en mode console avec la commande 'top', appuyez sur la touche k). Il reste cependant un problème : un processus s'exécute, nous le savons, avec les permissions de l'utilisateur qui l'a lancé. Un utilisateur ne peut supprimer qu'un processus qu'il a lancé, seul root peut tuer n'importe quel processus. Votre outil de surveillance habituel devrait normalement être lancé à partir de votre compte utilisateur, ce qui veut dire que vous ne pourrez pas tuer les processus des autres utilisateurs de cette façon.

Si un processus lancé par root ou par un autre utilisateur se comporte de façon anormale, vous devez vous connecter sous le compte 'root' dans une console en utilisant la commande su. Vous pouvez soit tuer le processus via son identifiant (PID) soit par son nom.

Si vous ne connaissez pas son PID, vous pouvez l'obtenir ainsi :

~# ps aux \-\-sort  %cpu

~# kill -9 PID

~# kill -KILL PID

Vous pouvez aussi tuer un processus en 'l'appelant par son nom'. Remarquez que c'est un peu plus risqué, car vous pouvez malencontreusement tuer ainsi des processus que vous ne souhaitiez pas tuer (ou au contraire n'en tuer aucun). La commande est alors :

~# killall -9 nom_du_processus

~# killall -KILL nom_du_processus

Si vous utilisez un système Unix autre que Linux, lisez bien la page 'man' associée à la commande 'killall'. Certains systèmes Unix interprètent littéralement la commande ('tout tuer') ce qui peut être gênant...

Notez que le signal '9' (SIGKILL) est un peu brutal, on recommande souvent d'utiliser d'abord le signal '15' (SIGTERM), qui donne le temps au processus de régler toutes ses affaires terrestres avant de mourir, de 'faire le ménage' :

~# kill -15 PID

~# kill -TERM PID

c'est seulement si le signal '15' SIGTERM ne réussit pas à le faire disparaître que vous vous devriez alors vous résoudre à utiliser le signal '9' SIGKILL.

Notez que c'est ce qui se passe chaque fois que vous arrêtez le système, si vous y prenez garde vous verrez s'afficher à ce moment des lignes telles que les suivantes :

Sending all processes the TERM signal\.\.\.
Sending all processes the KILL signal\.\.\.

Signalons au passage qu'il est possible d'envoyer un signal de votre choix à un processus en utilisant les outils graphiques de surveillance évoqués à la page précédente dans la section Agir sur les processus. En général, il suffit de passer par l'entremise d'un menu contextuel apparaissant en cliquant droit sur un processus sélectionné.

Il existe aussi une façon particulière de s'y prendre pour tuer un processus qui tourne en tâche de fond.

Pour tuer une session du shell en console (mais cela tuera aussi tous les processus qui y tournent : il vaut mieux les avoir tués 'proprement' avant, selon les méthodes indiquées plus haut), on peut utiliser le raccourci clavier Ctrl+D.

Un type plutôt inoffensif de 'mauvais' processus est le Zombie (Statut Z, ou 'defunct'). Si vous avez lu la page précédente, vous savez que les processus peuvent avoir des 'enfants' (qu'on appelle aussi des processus fils). Si le processus père/parent se termine normalement, il envoie un signal de fin à tous ses fils. Si le processus père se termine de façon anormale, alors il n'a pas toujours pu envoyer avant de mourir le signal de fin à ses fils. Sans leur processus père, ces processus deviennent des zombies : ils apparaissent toujours dans la table des processus, mais ils n'utilisent plus de ressources et il est impossible d'accéder à eux. À la différence de leurs homonymes, les processus zombies ne font aucun mal ;-) Ils disparaîtront tout naturellement au prochain redémarrage du PC.

Index de la section Administration du système - Index de la Base de Connaissances

Autres ressources

Sur les problèmes généraux relatifs à l'utilisation de la mémoire (virtuelle, segmentée, paginée, cache etc.) on pourra lire avec fruit les sections 6.1 et 2.2.5 de * Architecture de l'ordinateur * par Andrew Tanenbaum, Pearson Education.
man top
man free
man kill~~
man killall~~
Les raccourcis clavier de Linux
Outline of the Linux Memory Management System

Traduit par esfa - octobre/novembre 2004 - Révision par ptyxs (novembre 2005) - Dernière révision septembre 2006.

Legal: This page is covered by the GNU Free Documentation License. Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft.