Linux PSI Il me fournit des indicateurs qui montrent depuis combien de temps les tâches attendent du temps CPU, de la mémoire ou des E/S, et met ainsi en évidence les véritables goulots d'étranglement. Cela me permet d'identifier avec précision les moments où les systèmes se bloquent, au lieu de me contenter de mesurer la charge, et de définir, à partir des valeurs de pression, des mesures directes pour l'analyse des performances et la surveillance.
Points centraux
- partiel/complet: Signal d'alerte précoce ou blocage critique
- CPU/mémoire/E/S: charges clairement séparées par ressource
- avg10/60/300: Période d'évaluation des tendances
- Cgroups: Identifier les responsables et les personnes concernées
- Déclencheur: Réaction automatique en cas de dépassement d'un seuil
Ce que mesure Linux PSI et pourquoi c'est important
Je vais lire un extrait de Pression-Des indicateurs permettent de mesurer le temps de travail effectif perdu par les processus en raison d'un manque de temps CPU, de mémoire vive ou d'E/S. Les indicateurs classiques de charge ne montrent que le niveau d'utilisation des ressources, tandis que PSI révèle la fréquence à laquelle le système est effectivement à l'arrêt. C’est précisément ce qui permet de faire la distinction entre une file d’attente courte et un blocage complet. Dans les environnements dynamiques utilisant des conteneurs et des déploiements denses, cela me permet de détecter plus tôt les goulots d’étranglement et de les attribuer clairement à une ressource. Je peux ainsi hiérarchiser de manière ciblée les mesures d’optimisation et m’épargner les conjectures quant à la véritable Cause.
Activer et vérifier PSI sous Linux
Je vérifie d'abord si PSI est actif en consultant les fichiers situés dans /proc/pressure Je vérifie : si les valeurs relatives au processeur, à la mémoire et aux E/S y figurent, tout est prêt. En cas de données manquantes, j'active PSI à l'aide du paramètre de démarrage du noyau psi=1 ou je m'assure que CONFIG_PSI=y est défini dans le noyau. Cette fonctionnalité est disponible à partir du noyau 4.20 et est souvent déjà activée dans les distributions actuelles. Pour des vérifications rapides, de simples commandes telles que `cat /proc/pressure/cpu` suffisent ; elles me fournissent les valeurs avg10, avg60, avg300 et total. Je sais ainsi en quelques secondes si mon système dispose de données significatives Métriques est mis à disposition.
Comprendre les fichiers situés dans /proc/pressure
Dans /proc/pressure, on trouve trois fichiers pour CPU, memory et io, qui génèrent chacun deux types de sorties : « some » et « full ». « some » indique qu'au moins une tâche a dû attendre, tandis que « full » signifie que toutes les tâches non inactives sont bloquées simultanément. Je dispose également de moyennes mobiles sur 10, 60 et 300 secondes, ainsi que d'une valeur totale cumulée. Ces plages de temps me permettent de distinguer les pics de courte durée des problèmes persistants. Je peux ainsi évaluer objectivement s'il s'agit uniquement de pics isolés ou d'une situation persistante Pression est disponible.
« some » vs « full » en pratique
Je considère « some » comme un indicateur précoce et « full » comme une alerte grave, car « full » décrit des phases où le travail productif est de fait bloqué. Si « some » augmente au niveau du processeur, je vérifie la planification, les verrous et la répartition de la charge ; dans ce cas, l'optimisation des threads ou la mesure de la Mesurer la latence du planificateur. Des valeurs élevées de « memory-some » indiquent souvent des récupérations de pages, du swap ou des allocations gourmandes en ressources. Si « io-some » augmente, je vérifie les files d'attente, les priorités et les accès concurrents. Je ne prends pas mes décisions au feeling, mais en me basant sur des critères clairs Signaux.
Évaluation à l'échelle du système vs. évaluation basée sur les cgroups
Je commence par examiner les éléments à l'échelle du système Valeurs, afin d'avoir une vue d'ensemble, puis je passe à Cgroups pour identifier les sources. Avec cgroup v2, je trouve des fichiers « pressure » spécifiques à chaque service ou conteneur, ce qui me permet de les associer à des pods, des slices ou des unités. Cette approche permet de distinguer les symptômes des sources, au lieu d’imputer globalement toutes les charges à l’hôte. Je peux ensuite ajuster de manière ciblée les quotas, les parts de CPU ou les limites de mémoire. Je renforce ainsi l’équité et réduis les interférences mutuelles Influence.
PSI dans le suivi, les tableaux de bord et Kubernetes
Je collecte rarement les données PSI manuellement ; je laisse plutôt Exporter exporter les données au format séries chronologiques les collecter afin que les tableaux de bord puissent mettre en évidence les tendances et les corrélations. Dans Kubernetes, je lis les PSI au niveau des nœuds, des pods et des conteneurs, ce qui permet une distinction claire entre la consommation et les goulots d’étranglement pour chaque charge de travail. Je peux ainsi déterminer si un pod isolé augmente les temps d’attente pour les autres ou si le problème touche l’ensemble du nœud. Je configure des alertes sur les évolutions de la valeur « full » et sur les valeurs « some » élevées et persistantes. Cela me permet de réagir de manière proactive avant que les utilisateurs ne subissent des temps d’attente sentir.
Scénarios d'utilisation typiques et seuils pertinents
J'utilise PSI lors des tests de charge pour vérifier si les temps de réponse augmentent en raison d'une charge excessive sur le processeur, la mémoire ou les E/S, et si cette augmentation est temporaire ou permanente. Dans le cadre de la planification des capacités, je surveille l’indicateur avg300 afin d’identifier les tendances récurrentes et d’augmenter les ressources ou de rééquilibrer les charges de travail en temps utile. Pour l’autoscaling, j’utilise des déclencheurs proches du seuil à partir duquel l’état « full » se produit, afin de pouvoir réagir à temps. En cas de dégradation progressive des performances, je compare les références avant et après les mises à jour afin de mettre en évidence les effets. Je prends ainsi des décisions fondées sur des faits et j’investis là où le plus Effet se pose.
Tableau récapitulatif des indicateurs PSI
Lorsque je consulte PSI, j'utilise un système de classification simple qui me permet d'aboutir plus rapidement à la bonne hypothèse. Le tableau suivant résume l'interprétation des valeurs « some » et « full » par ressource et propose des premières pistes d'action. Il ne remplace pas une analyse approfondie, mais me fait gagner un temps précieux en production. Il reste essentiel de différencier l'évaluation des pics de courte durée de celle des phases plus longues. C'est précisément pour cela que j'utilise les moyennes glissantes avg10, avg60 et avg300 comme Contexte.
| Ressource | signal some | signal « full » | Causes fréquentes | Mesures envisageables |
|---|---|---|---|---|
| CPU | Périodes d'attente occasionnelles | Toutes les tâches sont bloquées | Conflits de planificateur, verrous, trop de threads | Ajuster les pools de threads, assouplir les verrous, ajuster les parts/quotas CPU |
| Mémoire | Reclaims, erreurs de page, engorgement d'allocation | Une forte pression, le swap domine | Surengagement, grands tas, pression sur le cache | Vérifier les limites, optimiser les allocations, réduire les opérations de swap |
| E/S | Des files d'attente qui s'allongent | I/O est un terme générique | Disques/réseau surchargés, accès concurrents | Priorités, regroupement des tâches, optimisation des files d'attente, volumes séparés |
Bien interpréter la pression dans l'accumulateur
J'analyse la valeur de `memory.pressure` en la mettant en relation avec le RSS, les taux de mise en cache et l'utilisation de l'espace d'échange, car seule cette combinaison permet de tirer des conclusions fiables. Souvent, un niveau élevé de `some` s'explique par une phase de libérations intensives ou par une augmentation des `page-faults`, qui peut être atténuée grâce à de meilleurs modèles d'allocation. Si « full » apparaît, j’interromps les expérimentations et je commence par réduire la pression à l’aide de limites ou de caches moins agressifs. Pour une approche plus approfondie du sujet, je me réfère à Pression sur la mémoire avec des conseils pratiques sur l'optimisation de la mémoire vive. Voici comment j'évite que le swap incontrôlé n'allonge les temps de réponse domine.
Identifier et résoudre les goulots d'étranglement au niveau des E/S
J'analyse io.pressure en parallèle des latences, des taux de remise en file d'attente et des profondeurs de file d'attente, car les valeurs de débit seules masquent les goulots d'étranglement. Un some élevé pour une charge modérée m'indique souvent des profils d'accès irréguliers, qui peuvent être lissés grâce au traitement par lots ou à la priorisation. En cas de délais de premier octet et d’augmentation de la valeur « full », je mise sur le découplage via des E/S asynchrones et des volumes séparés pour les chemins d’accès fréquents. Pour des diagnostics détaillés, j’utilise des séries de mesures et le guide éprouvé au quotidien sur Analyser l'attente d'E/S. Cela me permet de prendre des décisions ciblées plutôt que Présomptions.
PSI vs. charge moyenne et indicateurs classiques
Je place délibérément PSI aux côtés de la charge moyenne, de l'utilisation du processeur, de l'iowait et de l'utilisation de la mémoire, afin de combler les lacunes entre ces différents points de vue. Une charge élevée associée à une faible valeur de cpu.pressure m'indique souvent simplement que de nombreuses tâches peuvent s'exécuter activement, sans engorgement à l'échelle du système. À l’inverse, une augmentation de la cpu.pressure avec une charge modérée indique des conflits de planification ou des conflits de verrouillage. En matière d’E/S, l’iowait à lui seul ne me dit pas dans quelle mesure le système dans son ensemble en souffre ; l’io.pressure quantifie le temps de travail perdu à cet égard. C’est précisément cette conversion de la “ charge ” en “ temps perdu ” qui rend mes décisions nettement plus fiables.
Lire les fenêtres AVG avec une précision absolue
Je considère les valeurs avg10/60/300 comme des pourcentages du temps pendant lequel les tâches ont été bloquées. Un avg10 de 2,50 signifie qu’au cours des 10 dernières secondes, 2,51 TP3T de temps de travail potentiel ont été perdus. La valeur « total » cumule le temps d’arrêt depuis le démarrage (en unités de temps très fines) et m’indique ainsi le Aire sous la courbe. Pour la planification des capacités, j'observe la pente des profils globaux et quotidiens : si la courbe devient nettement plus raide pendant les pics d'activité, je prévois des mesures d'allègement. Pour les signaux opérationnels, j’analyse les tendances : une brève flambée de l’avg10 m’inquiète moins qu’une hausse parallèle de l’avg60 et de l’avg300, qui indique une pression structurelle.
Les cgroups en pratique : structure, chemins d'accès et droits d'accès
Je travaille avec cgroup v2 en utilisant les fichiers « pressure » directement dans les répertoires respectifs des services, des tranches ou des pods. Cela me permet de déterminer, pour chaque unité, pod ou conteneur, si la pression est générée localement ou si elle est simplement transmise. Les unités systemd, les pods Kubernetes et les groupes définis par l’utilisateur peuvent ainsi être clairement distingués les uns des autres. Une fois l’attribution effectuée, je procède à un régulage ciblé : des quotas CPU plus stricts, des parts CPU plus équitables, des limites de mémoire plus réalistes. Concrètement, je veille à effectuer la mesure là où elle produit ses effets, c’est-à-dire précisément dans le Cgroup qui définit les limites. Cela m’évite de lutter contre les symptômes à un endroit alors que la source réelle reste intacte.
Stratégies d'alerte sans avalanche d'alertes
Je définis les alertes de manière à ce qu'elles tiennent compte des tendances et de la persistance. Pour la détection précoce, je définis des seuils à « some », je les combine avec des fenêtres d'observation et une hystérésis, puis je vérifie si avg10 et avg60 reste élevé. Pour les interventions urgentes, j’associe « full » à des fenêtres courtes et à des réactions automatiques (mise à l’échelle, priorisation, limitation). Afin d’éviter les oscillations, je ne déclenche l’intervention que lorsqu’un état a été confirmé à plusieurs reprises, et je ne reviens à l’état initial que lorsque les valeurs tombent nettement en dessous du seuil de retour. J’associe les alertes aux SLO des services : si les latences p95 augmentent et que la charge s’accroît simultanément, le constat est fiable – la charge seule ne me suffit pas pour cela.
Exemples concrets : des schémas que je reconnais immédiatement
J'aime recenser les schémas récurrents, car ils permettent d'accélérer la prise de décision :
- CPU : des conflits de verrouillage plutôt qu’un “ nombre insuffisant de cœurs ” – La valeur de « cpu.some » augmente alors que l'utilisation du processeur n'atteint pas ses limites. J'étudie les « hotlocks », je réduis la répartition des threads et je lisse les pics à l'aide de la contre-pression. Cela s'avère souvent plus efficace que d'ajouter des cœurs supplémentaires.
- Mémoire : la spirale de la reconquête – La valeur « memory.some » augmente et fluctue avec les erreurs de page, tandis que le swap s'active. Je diminue l'agressivité du cache, je réduis les pics de la mémoire dynamique (par exemple, la taille des lots), j'ajuste les limites et j'empêche ainsi que la valeur « memory.full » n'apparaisse.
- E/S : Accès non équilibrés – io.some augmente alors que le débit reste normal. Je sépare les chemins de lecture et d'écriture, je regroupe les petites opérations d'E/S en lots et je répartis les chemins les plus sollicités sur des volumes distincts. Je réduis ainsi les temps d'attente sans pour autant augmenter nécessairement le débit pur.
Limites et obstacles à l'interprétation
Je garde à l'esprit que PSI mesure le temps d'attente, et non la charge absolue. Un job batch « CPU-bound » peut afficher une charge élevée sans augmenter la valeur cpu.pressure, tant qu'il y a suffisamment de cœurs disponibles. À l'inverse, un faible débit associé à une valeur io.pressure élevée peut indiquer un engorgement manifeste. Dans les environnements virtualisés, je vérifie également si des limites ou des affinités génèrent des goulots d’étranglement locaux : un conteneur qui n’est affecté qu’à quelques cœurs peut afficher une forte valeur de cpu.pressure, même si l’hôte dispose de ressources libres. Il est également important de comparer la vue à l'échelle du système et celle au niveau du cgroup – c'est la seule façon de déterminer si je résous le problème au bon endroit.
Indicateurs opérationnels : échantillonnage, frais généraux et visualisation
Je privilégie un échantillonnage simple : un intervalle de 1 à 5 secondes me suffit pour prendre des décisions opérationnelles, car les fenêtres « avg » assurent déjà un lissage. Je considère que la surcharge liée à PSI est négligeable, d’autant plus que je réalise les mesures au plus près du système et que je n’enregistre que quelques séries chronologiques bien ciblées. Pour la visualisation, j’affiche côte à côte des panneaux par ressource (some/full, avg10/60/300, total) et je les mets en corrélation avec les taux de latence et d’erreurs. Lors des analyses rétrospectives, je trace la pente de la valeur « total » en fonction des déploiements, des versions ou des changements de configuration – cela permet de voir clairement quelles mesures réduisent réellement la charge.
Mesures correctives ciblées par ressource
Je déduis des mesures concrètes à partir de ces schémas, sans me précipiter pour acheter du matériel supplémentaire :
- CPU: Limiter les pools de threads et les garde-fous de concurrence, désamorcer les « hotlocks » (granularité/stratégie de verrouillage), répartir équitablement la charge (parts/quotas), tenir compte de la topologie (NUMA, affinité). Ce n’est que lorsque l’allègement local ne suffit pas que je procède à une évolutivité horizontale ou verticale.
- Mémoire: Stabiliser les allocations (traitement par lots, mémoire tampon), modérer l'utilisation des caches, définir des limites réalistes, lisser les pics de mémoire, réduire l'impact de l'échange. Je procède à des mesures ciblées avant et après les modifications, car memory.some est sensible aux schémas d'allocation.
- E/S: Lisser les profils d'accès (traitement par lots, E/S asynchrones), découpler les « hotpaths », définir des priorités, choisir des profondeurs de file d'attente adaptées et désenchevêtrer les charges de travail concurrentes. J'évalue les résultats à l'aune de la baisse de la pression d'E/S et de la réduction des latences P99.
Le PSI au quotidien dans le travail d'équipe : communication et appropriation
J'utilise également PSI comme langage commun entre les équipes de la plateforme et celles des produits. Au lieu de parler de manière abstraite de “ lenteur ”, je nomme la ressource et le schéma : “ io.some avg60 au-dessus de 4% depuis 20 minutes pour le service X ” ou “ memory.full se déclenche dans le cgroup Y ”. Cette précision facilite la hiérarchisation des priorités, car elle permet d’identifier clairement les responsables qui doivent intervenir et le budget (temps, ressources) susceptible d’avoir le plus grand impact. À partir de références définies, je fixe des objectifs de qualité à la fois techniquement solides et compréhensibles pour les parties prenantes.
Déclencheurs, lignes de base et déploiement progressif
J'utilise des déclencheurs PSI avec des seuils et des fenêtres d'observation afin qu'un démon réagisse automatiquement en cas de pression persistante. Pour obtenir des résultats fiables, je crée avant toute modification une référence basée sur les phases de charge typiques, que je compare ensuite à de nouvelles séries de mesures. Je définis les alertes de manière prudente : le niveau « some » (augmentation persistante) me laisse du temps, tandis que le niveau « full » déclenche des contre-mesures. Dans les grands parcs, je déploie les alertes basées sur PSI par étapes afin d'éviter le « bruit » et d'ajuster précisément les tolérances. Ainsi, ma surveillance reste clair comme de l'eau de roche et fiable, sans submerger les équipes de notifications inutiles.
Avantages pour l'hébergement, la virtualisation et l'architecture multi-locataires
Grâce à PSI, je peux voir si certaines charges de travail en ralentissent d’autres, si les réserves matérielles sont suffisantes et où il faut ajuster les limites. Dans les environnements partagés, je détecte les pressions persistantes exercées sur le processeur, la mémoire ou les E/S par certains comptes et je planifie les réaffectations en temps utile. Les métriques basées sur les cgroups m’indiquent quels services sont concernés et où je dois limiter ou prioriser de manière ciblée. Je garantis ainsi des temps de réponse fiables et veille à une utilisation équitable des ressources, même en cas de charge élevée. Cela réduit les coûts, évite les escalades et améliore sensiblement la Qualité.
Conclusion : les indicateurs permettent de prendre des décisions
J'utilise Linux PSI car cet outil permet de mesurer les temps d'attente et comble ainsi le fossé entre la charge système et l'expérience utilisateur. Avec « some », je détecte les premiers signes avant-coureurs ; avec « full », je réagis aux véritables blocages ; et avec les Cgroups, j'identifie précisément leurs causes. Les tableaux de bord, les déclencheurs et les références transforment cette vision en mesures concrètes : limites optimisées, meilleure répartition de la charge, chemins d’E/S propres. Ceux qui utilisent activement PSI réduisent le temps nécessaire pour identifier la cause et s’épargnent de nombreux cycles de réglage à l’aveuglette. Ainsi, les données de surveillance deviennent des Décisions, qui accélèrent sensiblement les systèmes.
