Sur les systèmes d’exploitation SunOS et Solaris (ainsi que sur leurs dérivés comme OpenIndiana ou SmartOS), la surveillance en temps réel de l’activité du processeur ne repose pas historiquement sur l’outil standard top, souvent absent des installations minimales. Pour diagnostiquer une surcharge système ou identifier un processus qui monopolise le processeur, l’outil de référence natif est prstat.
Qu’est-ce que la commande prstat ?
L’utilitaire prstat examine périodiquement tous les processus actifs et affiche des statistiques triées selon des critères définis. Contrairement à des commandes statiques comme ps, il rafraîchit son affichage de manière continue, à la façon d’un moniteur de performances interactif. Il offre une granularité très fine, notamment la visibilité sur les threads légers (LWP pour Lightweight Process), les conteneurs (Zones Solaris) et les projets de gestion de ressources.
Les options indispensables pour le diagnostic
Dans sa syntaxe de base, prstat liste tous les processus. Pour isoler rapidement les consommateurs de ressources, plusieurs paramètres sont essentiels :
- Trier par utilisation du processeur : prstat -s cpu organise la liste en plaçant les processus les plus gourmands en tête.
- Limiter le nombre de lignes affichées : pour ne pas encombrer le terminal, l’option -n permet de restreindre l’affichage (ex. prstat -s cpu -n 10 pour le top 10).
- Afficher l’activité par utilisateur : avec l’option -a, la commande ajoute une section récapitulant la consommation globale par compte utilisateur (CPU, mémoire, nombre de processus).
- Inspecter les threads légers (LWP) : très utile pour les applications multithreadées comme les serveurs d’applications Java ou les bases de données, l’option -L affiche le détail de chaque thread au lieu d’agréger les données au niveau du processus parent.
- Surveiller les Zones Solaris : dans un environnement virtualisé avec conteneurs, prstat -Z ventile la consommation par zone (globale et non-globales).
Comprendre les colonnes de sortie
L’en-tête retourné par prstat fournit plusieurs métriques capitales pour l’administrateur système :
- PID : l’identifiant unique du processus.
- USERNAME : le propriétaire exécutant la tâche.
- SIZE et RSS : SIZE représente la mémoire virtuelle allouée au processus (y compris les bibliothèques partagées), tandis que RSS (Resident Set Size) indique la quantité de mémoire physique réelle résidant en RAM.
- STATE : l’état d’ordonnancement (run pour actif sur un cœur, sleep en attente d’un événement ou d’une entrée/sortie).
- CPU : le pourcentage de temps de calcul consommé durant l’intervalle d’échantillonnage.
- PROCESS/NLWP : le nom de l’exécutable et son nombre de threads natifs (par exemple java/242 indique une instance JVM gérant 242 threads concurrents).
Gérer les processus hors de contrôle
Lorsqu’un binaire sature un cœur CPU à 100 % de façon anormale (boucle infinie, deadlock applicatif), il est souvent nécessaire d’intervenir. Si vous devez stopper le processus récalcitrant, évitez d’envoyer immédiatement un signal destructeur :
- Tentez d’abord un arrêt propre avec kill -15 <PID> (signal SIGTERM), ce qui laisse au programme le temps de libérer ses verrous et sockets réseaux.
- Si le processus ne répond plus du tout après plusieurs secondes, recourez alors au signal ultime : kill -9 <PID> (SIGKILL).
Avant toute suppression radicale, vérifiez si le comportement anormal n’est pas provoqué par un problème sous-jacent : un système de fichiers saturé (à contrôler via les outils pour afficher la taille de partition linux / Solaris), un message d’erreur matériel visible lors d’un debug avec dmseg, ou un chemin d’exécution faussé par une variable d’environnement Unix mal initialisée.
