Passer au contenu 
Avec pidstat Sous Linux, je mesure l'activité du processeur, de la mémoire, des E/S et des threads pour chaque processus à intervalles réguliers, ce qui me permet de dégager des tendances plutôt que de me contenter d'instantanés. C'est ainsi que je découvre Goulots d'étranglement fiable, associez-la à un PID ou à une commande et déterminez si la cause réside dans le processeur, la mémoire vive, les E/S ou un changement de contexte.
Points centraux
- Mesure par intervalles: des séries chronologiques par processus plutôt qu'un simple instantané.
- Large couverture: CPU, mémoire, E/S, threads et changements de contexte.
- Filtrage ciblé: Observation ciblée via PID ou commande.
- Facilité d'utilisation: installer sysstat, le lancer directement.
- Avantages pratiques: Identifier rapidement les pics de charge, les fuites et les goulots d'étranglement au niveau des E/S.
Qu'est-ce que pidstat ? Explication succincte
J'utilise pidstat, afin de mettre en évidence l'utilisation des ressources par chaque processus au fil du temps. Cet outil fait partie du pack sysstat et fournit, pour chaque processus, des données sur l'utilisation du processeur, de la mémoire, des E/S, des threads et des changements de contexte. Contrairement à top, je n’obtiens pas un aperçu fugace, mais des mesures continues à intervalles réguliers. Cela me permet de détecter des tendances telles que des pics périodiques, une charge constante ou une augmentation progressive. Ces informations temporelles m’aident à attribuer clairement les causes à un processus et à ne pas me perdre dans le bruit d’un instantané.
Installation et mise en service rapide
J'installe sysstat à l'aide du gestionnaire de paquets de ma distribution, puis je lance immédiatement pidstat sans configuration supplémentaire. La syntaxe de base reste simple : pidstat [options] [intervalle] [nombre]. Sans option, l'outil affiche CPU- Valeurs par processus ; les mesures sont répétées en continu à un certain intervalle. Exemple : pidstat 2 10 Je collecte dix mesures toutes les deux secondes. Cela me permet de constituer rapidement une chronologie fiable pour la suite de l'analyse.
Analyse du processeur : visualiser la charge par processus
Pour les questions concernant le processeur, je commence par pidstat avec -u, par exemple pidstat -u 1 pour le cadence en secondes. Les colonnes %usr, %system et %CPU m'indiquent le temps utilisateur et le temps noyau consommés par un processus. Si je souhaite me concentrer sur une application, j'utilise -p ou -C pour les filtres par nom. Si %system augmente fortement, je vérifie les appels système ou les influences des E/S ; si %usr domine, le travail se situe dans l'espace utilisateur. Pour une analyse plus approfondie par processus, je renvoie, si nécessaire, à Comptabilité par processus, afin d'analyser les données d'utilisation de manière structurée.
Vérifier de manière ciblée l'utilisation de la mémoire
En ce qui concerne les sujets liés à la RAM, -r des informations précieuses, par exemple grâce à pidstat -r -p 1234 1. Je surveille l'évolution de la mémoire virtuellement occupée et de la mémoire résidente au fil des minutes, et je vérifie si le nombre de « page faults » augmente. Si la consommation augmente progressivement par petits paliers, je détecte rapidement d'éventuelles fuites. Si la consommation reste constante et n'augmente que pendant de courtes périodes, cela indique une utilisation légitime Mise en cache . Grâce à la mesure par intervalles, je distingue clairement les valeurs aberrantes des tendances réelles.
Comprendre les opérations d'E/S et les changements de contexte
Avec -d j'affiche l'activité de lecture et d'écriture par processus, ce qui me permet d'identifier les causes des temps d'attente élevés au niveau du périphérique de stockage. Des taux de transfert élevés associés à des latences croissantes laissent supposer l'existence de goulots d'étranglement au niveau du stockage. En complément, je vérifie à l'aide de -w le nombre de changements de contexte par seconde, car des changements excessifs peuvent générer une surcharge inutile. Un nombre élevé de changements volontaires (vswch/s) indique une synchronisation ; un nombre élevé de changements forcés (cswch/s) indique une forte concurrence pour le temps CPU. C'est ainsi que j'identifie les charges de travail inefficaces, que je résous de manière ciblée.
Surveiller les threads et identifier les points chauds
J'utilise -t, pidstat fournit également des valeurs relatives aux threads pour chaque processus. Cela me permet de voir si certains workers d'une application sortent des normes. Pour Java, PHP-FPM, les bases de données ou les workers de file d'attente, je peux ainsi identifier les threads qui monopolisent le processeur ou font augmenter l'utilisation de la mémoire. Si je détecte des déséquilibres, j’ajuste les pools de threads, les affinités ou Limites . Cette approche m'aide à optimiser non seulement les processus, mais aussi leur parallélisme interne.
Aperçu des options importantes
J'utilise les commutateurs principaux de manière ciblée pour Analyses pour rester concentré et garantir la lisibilité des résultats. Le tableau suivant résume de manière concise les options principales et les utilisations typiques. Je peux ainsi choisir rapidement le commutateur adapté pour le processeur, la mémoire, les E/S, les threads ou les filtres. Des exemples m’aident à me lancer sans détours. Chaque ligne me fournit une Remarque en fonction de l'usage prévu.
| Option | Fonction | Exemple |
|---|---|---|
-u | Afficher l'utilisation du processeur par processus | pidstat -u 1 |
-r | Valeurs relatives à la mémoire et aux erreurs de page | pidstat -r -p 1234 2 |
-d | Activité d'E/S lecture/écriture | pidstat -d 1 |
-w | Changement de contexte par processus | pidstat -w -p 1234 1 |
-t | Afficher les statistiques du fil de discussion | pidstat -t -p 1234 1 |
-p | Limiter à des identifiants de processus spécifiques | pidstat -u -p 1234 1 |
-C | Filtrer les processus par commande | pidstat -C php-fpm 2 |
Filtres, intervalles et surveillance ciblée
Je prévois d'effectuer des mesures avec Intervalles, qui correspondent à la question posée : des secondes pour les sprinteurs, des minutes pour les coureurs de fond. À propos de -p et -C Je limite l'affichage aux processus pertinents et je veille à ce que la console reste claire. pidstat 2 10 C'est idéal pour les tests courts ; sans spécifier de nombre, je mesure en continu jusqu'à ce que j'interrompe le processus. Pour les vérifications récurrentes, j'enregistre les commandes dans des scripts et je documente les Ligne de base d'un système. Cette routine permet de gagner du temps si les problèmes de charge se reproduisent.
Comparaison avec top, ps et autres.
Pour un aperçu rapide, j'utilise top ou ps, mais pour suivre l'évolution et obtenir des informations détaillées, j'utilise pidstat. Les valeurs par intervalle me permettent d'identifier les causes au fil du temps plutôt que de me contenter d'observer les symptômes. Si j'ai besoin d'une analyse plus approfondie des goulots d'étranglement au niveau du processeur, je complète l'analyse avec Linux perf pour des échantillons de piles d'appels. C'est ainsi que je combine les statistiques de processus avec le profilage lorsque les seules valeurs de charge ne suffisent pas. Cette combinaison me fournit des indications rapides et une analyse approfondie Diagnostic.
Astuces pratiques pour le quotidien
Je garde à disposition des commandements qui ont fait leurs preuves et je les adapte en fonction de la situation pour Systèmes de production. Charge du processeur en temps réel : pidstat -u 1. Mémoire ciblée : pidstat -r -p 2. Vérifier s'il y a un goulot d'étranglement au niveau des E/S : pidstat -d 1. Les fils de discussion à suivre : pidstat -t -p 1. Pour une instrumentation plus approfondie du système, je recommande en complément Astuces bpftrace lorsque des événements du noyau nécessitent Spotlight.
Bien interpréter les résultats : axes temporels et systèmes multicœurs
Je fais attention à la manière dont pidstat définit les références temporelles : le premier bloc de mesure Affiche par défaut les valeurs moyennes depuis le lancement du processus (ou depuis le démarrage du système) ; tous les blocs suivants se rapportent à l'option sélectionnée Intervalle. Pour effectuer des analyses approfondies, j'ignore souvent le premier bloc et je ne prends en compte que les valeurs d'intervalle comparables dans le temps.
À l'adresse suivante : Systèmes multicœurs J'interprète toujours la valeur %CPU en fonction du nombre de cœurs disponibles. Sur un hôte à 8 cœurs, un processus unique peut théoriquement atteindre jusqu'à 800% s'il s'étend sur plusieurs threads. Des valeurs élevées de %system m'amènent à penser à des appels système, à des conflits de verrouillage ou à des files d'attente d'E/S ; des valeurs élevées de %usr indiquent des routines gourmandes en ressources de calcul dans l'espace utilisateur. L’horodatage figurant avant chaque ligne permet d’identifier clairement les valeurs aberrantes dans l’historique et facilite la corrélation avec les journaux ou les métriques provenant d’autres sources.
Méthodologie : formuler des hypothèses, choisir des fenêtres de mesure
Je ne me lance jamais à l'aveuglette, mais je formule une Hypothèse Concernant les causes : „ CPU-bound dans l'espace utilisateur “, „ file d'attente d'E/S encombrée “, „ la mémoire augmente constamment “. J'en déduis la durée de la fenêtre de mesure : pour les pics de courte durée, j'utilise des intervalles de 1 à 2 secondes, pour aux skieurs de fond plutôt entre 10 et 60 secondes. Il est important d'adapter la fenêtre à la Dynamique du système afin de ne perdre aucun détail et de ne pas capter inutilement trop de bruit.
Je prends également des mesures avant et après Modifications (par exemple, mise en production, optimisation de la configuration) afin de mettre en évidence les effets sur les indicateurs. Une analyse rigoureuse Ligne de base par environnement (DEV, STAGE, PROD) m'aide à distinguer les écarts réels par rapport aux schémas habituels.
Enregistrement et suivi à long terme
Lorsque les problèmes sont difficiles à cerner, je note mes observations pendant une période donnée, puis j'en tire des conclusions par la suite. Exemple : pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log collecte pendant 30 minutes les données relatives au CPU, aux E/S, aux changements de contexte et aux threads, à raison d'une mesure toutes les 2 secondes. Je peux générer une sortie textuelle structurée à l'aide de grep, awk ou un petit script post-traitement, marquer les pics et extraire les PID significatifs. Pour les observations récurrentes, je prévois de Schéma de rotation et ne réserve que les créneaux horaires pertinents afin de gagner de la place.
Lorsque j'ai besoin de plusieurs angles de vue, je combine plusieurs commutateurs au cours d'une même séquence, plutôt que de lancer plusieurs outils en parallèle. Cela permet de conserver les résultats de mesure synchrone et facilite l'analyse.
Conteneurs, espaces de noms et PID
Dans les environnements de conteneurs, les règles suivantes s'appliquent : Les PID sont associés à un espace de noms. Si je mesure au niveau de l'hôte, je vois les PID de l'hôte ; si je mesure au niveau du conteneur, je vois les PID du conteneur. Pour une identification sans ambiguïté, je préfère donc filtrer par nom de commande à l'aide de -C plutôt qu'avec un PID unique qui change après un redémarrage. Lorsque je travaille côté hôte, j'enrichis le contexte du processus (par exemple via le nom du service ou du pod dans les journaux) afin de pouvoir attribuer clairement les valeurs mesurées à un Charge de travail à attribuer. Pour les enregistrements de longue durée, j'évite le piège du PID (Réutilisation des PID) également grâce à des filtres par nom ou à des journaux d'accompagnement qui documentent la durée de vie du PID.
Mesures fiables en production : frais généraux, droits, protection des données
Overhead: pidstat lit principalement à partir de /proc et ne nécessite qu'un effort de mesure minime. Lorsque les intervalles sont très courts sur des hôtes fortement sollicités, j'augmente légèrement l'intervalle (par exemple, de 1 à 2 secondes) afin de réduire encore davantage l'impact sur le processeur. Je mesure de manière ciblée (filtres !) plutôt que „ tout et partout “.
Droits et sécurité: En fonction de la configuration du système (hidepid à l'adresse suivante : /proc) les détails ne sont pas visibles pour tous les utilisateurs. En environnement de production, j'utilise des droits étendus si nécessaire, je limite la durée de la mesure et je vérifie si l'affichage complet Lignes de commande pourrait révéler des paramètres sensibles. Les fichiers journaux contenant des données de diagnostic ne doivent être conservés que dans des emplacements où ils sont stockés et supprimés en toute sécurité.
Reconnaître rapidement les schémas typiques
- Système 1TP1 élevé avec une %usr modérée: Indication de points de goulot d'étranglement proches du noyau (utilisation intensive des appels système, contention sur les verrous, chemins d'accès aux pilotes réseau/stockage). Je mets cela en corrélation avec les valeurs d'E/S et les changements de contexte.
- Nombreux changements de contexte forcés (cswch/s): Forte concurrence pour le temps CPU, souvent due à des ressources CPU insuffisantes ou à un nombre trop élevé de threads actifs. Limiter l'utilisation, ajuster la taille des pools ou Affinités vérifier.
- De nombreux changements de contexte volontaires (vswch/s): Une synchronisation très marquée ou yieldles files d'attente basées sur [...]. Je m'interroge sur les verrous, les stratégies de backoff et le comportement des pools de threads.
- Une capacité de stockage en constante augmentation: Soupçon de fuite. Je vérifie si Page Faults (en particulier majflt) augmentent et si le processus libère de la mémoire après les pics de charge. Si ce n'est pas le cas, je le vérifie à l'aide d'une mesure à intervalles plus longs.
- Taux de transfert d'E/S élevés malgré un débit faible au niveau du système: Associées aux temps d'attente, les valeurs d'E/S des processus indiquent des goulots d'étranglement dans la pile de stockage sous-jacente. Je donne la priorité aux mesures d'optimisation des E/S (traitement par lots, mise en cache, E/S asynchrones).
- Certains fils de discussion se démarquent: Avec
-tje repère le „ thread chaud “ et j'ajuste le pool de threads ou j'analyse de manière ciblée son chemin d'exécution.
Exemples concrets de workflows
Identifier les opérations limitées par le processeur: Tout d'abord pidstat -u 1 de manière globale, puis de manière ciblée avec -p ou -C. Si le nombre de TP3Tusr augmente, je recherche le « hot thread » avec -t puis, si nécessaire, j'analyse les résultats à l'aide d'un profileur d'échantillonnage. Si les cycles %s dominent, je jette également un œil aux E/S et aux changements de contexte.
Confirmer la fuite de mémoire: Pendant plusieurs minutes avec pidstat -r -p 5 observer. Je constate une augmentation constante, sans baisse après les phases de charge. En parallèle, je vérifie si les taux de « page fault » ou les modèles d'E/S permettent d'expliquer ce comportement. Si la tendance persiste sans justification valable, c'est clairement un Indicateur de fuite.
Détecter un engorgement d'E/S: Avec pidstat -d 1 J'identifie les points sensibles en lecture/écriture. Si je constate une charge d'écriture importante due à un petit nombre de processus, je me concentre sur leurs chemins de vidage/synchronisation et la taille de leurs lots. La corrélation avec les changements de contexte m'aide à déterminer si le processeur est simultanément soumis à une forte charge.
Corriger le déséquilibre du filetage: pidstat -t -p 1 m'indique la charge et les changements de contexte pour chaque thread. Si un worker chauffe nettement plus que les autres, j'ajuste la taille des pools, la répartition des tâches ou Affinity et vérifie si la distribution se normalise dans les intervalles suivants.
Limites de pidstat et compléments utiles
pidstat affiche ce que a épuisé les ressources et quand cela se produit – cela n'explique pas automatiquement cela pourquoi dans le chemin d'accès au code. Pour comprendre le „ pourquoi “, j'utilise en complément des profileurs d'échantillonnage ou des points de trace du noyau. En ce qui concerne les questions de mémoire, pidstat met en évidence les tendances, mais pas les cycles de vie des objets. Je considère donc pidstat comme Premiers intervenants, qui me permet de cerner les problèmes avec un minimum d'efforts. Lorsque les simples valeurs de charge ne suffisent plus, j'approfondis l'analyse de manière ciblée à l'aide des outils déjà mentionnés.
Liste de contrôle pour un démarrage rapide
- Préciser la problématique: CPU, RAM, E/S, threads ou changement de contexte ?
- Sélectionner un intervalle: Quelques secondes pour les pics, quelques minutes pour les tendances.
- Définir des filtres:
-pou-Cpour alléger la sortie. - D'abord une vue d'ensemble, puis une analyse approfondie: Lancer une analyse globale, filtrer les processus suspects.
- Classer le premier bloc: La première ligne correspond à la moyenne depuis le début ; comparer ensuite les valeurs par intervalle.
- Limiter la durée de la mesure: Collecter suffisamment de données pour identifier les tendances, tout en gardant le contrôle sur les journaux.
- Documenter: Consigner la ligne de base, l'hypothèse, les paramètres de mesure et les observations : c'est ce qui rend les analyses reproductibles.
En bref
Avec pidstat Je reçois des données de processus basées sur le temps concernant le CPU, la RAM, les E/S, les threads et les changements de contexte, ce qui me permet d’identifier les véritables causes des profils de charge. La combinaison de filtres, d’intervalles et d’indicateurs clairs rend les analyses ciblées et reproductibles. Je repère les tendances au lieu de me laisser induire en erreur par des instantanés, et je mets en place les contre-mesures adaptées. Des commandes telles que pidstat -u 1, -r, -d et -w couvrent les cas les plus courants. C'est ainsi que je veille à ce que les systèmes restent transparents, que les décisions soient prises rapidement et que les diagnostics compréhensible.
