Procfs sous Linux pour les administrateurs : aperçu des fichiers importants

Le Linux procfs affiche l'état actuel du noyau via des fichiers virtuels situés dans le répertoire /proc. Pour l'administration, les éléments les plus pertinents sont notamment la charge, la mémoire, les processus, les descripteurs de fichiers et les périphériques bloc. Il est essentiel de bien replacer ces valeurs dans leur contexte : certaines sont des instantanés, d’autres des compteurs cumulés depuis le démarrage ou des moyennes glissantes. Ne vous fiez donc jamais à une seule valeur, mais recoupez-la avec les signaux appropriés et le contexte de l’hôte, de la machine virtuelle ou du conteneur.

Comprendre procfs : une vue virtuelle du noyau plutôt qu'un espace de stockage de données

Le procfs Il s'agit d'un système de fichiers virtuel : les entrées situées sous /proc reflètent les structures de données et les états du noyau Linux en cours d'exécution. Elles ne sont pas stockées de manière permanente sur un support de données. Lors de la lecture, le noyau génère la vue correspondante à partir de son état actuel ; après un redémarrage, de nombreux compteurs repartent par exemple de zéro. C'est pourquoi /proc est une interface destinée à l'observation et, en partie, au contrôle, et non un emplacement pour des fichiers personnels ou des configurations persistantes.

En matière d'administration, il convient de distinguer trois domaines. Les fichiers d'état globaux tels que /proc/meminfo, /proc/stat ou /proc/loadavg fournissent des indicateurs à l'échelle du noyau. Les répertoires portant des noms numériques, comme /proc/1234, fournissent des détails sur un processus individuel. Le répertoire /proc/sys, quant à lui, contient des paramètres du noyau qui peuvent être accessibles en lecture et en écriture, en fonction des droits d'accès et des paramètres concernés. La similitude de la structure des fichiers ne doit pas faire oublier que la consultation d'un état et la modification d'une configuration ont des conséquences fondamentalement différentes.

Les chemins et champs disponibles ne sont pas identiques sur tous les systèmes Linux. La version et la configuration du noyau, l’architecture, le matériel détecté ainsi que les modules chargés influencent les entrées visibles. Les espaces de noms modifient également certaines vues. Un procfs associé à un espace de noms PID limite notamment la vue des processus et des PID ; cela ne signifie toutefois pas que les fichiers globaux affichent automatiquement des valeurs spécifiques à un conteneur ou à un cgroup. Les scripts devraient vérifier les fichiers et les champs avant d’analyser leur contenu, plutôt que de partir du principe que la structure procfs est complète et identique partout.

Il convient de distinguer cela du sysfs situé sous /sys : celui-ci représente principalement des périphériques, des pilotes et des objets matériels. Le cgroup2 joue également un rôle important dans la répartition des ressources et la définition des limites des groupes. Le procfs reste toutefois la source directe de nombreux états du noyau et des processus, nécessaires lors d'un premier diagnostic.

Bien interpréter les chiffres, les instantanés et la visibilité

Avec procfs, cette valeur ne suffit généralement pas à elle seule à expliquer un problème. Il faut d’abord clarifier son contexte temporel : certaines données sont compteurs cumulatifs depuis le démarrage du système, d'autres décrivent un état actuel, d'autres encore représentent des plages de temps glissantes. Un compteur à un niveau élevé indique dans un premier temps uniquement qu'un événement s'est accumulé depuis le démarrage. Un débit ne peut être calculé qu'à partir de deux points de mesure : la différence entre les valeurs divisée par l'intervalle de temps qui les sépare. Cela s'applique par exemple à de nombreux compteurs de CPU, d'interruptions et de supports de données.

Le fichier /proc/uptime fournit la durée de fonctionnement écoulée et le temps d'inactivité cumulé. Il permet de situer chronologiquement les compteurs depuis le démarrage, mais ne remplace pas une série de mesures. Une requête ponctuelle ne constitue qu'un instantané ; pour obtenir des informations fiables sur les tendances, les pics ou les charges récurrentes, il faut effectuer des requêtes répétées avec horodatage. Les valeurs peuvent d'ailleurs évoluer pendant la lecture, car le noyau continue de fonctionner.

Les données visibles ont elles aussi leurs limites. /proc/self renvoie toujours au processus qui est en train de résoudre le chemin d'accès. Il est donc pratique pour les scripts et les vérifications interactives, sans qu'il soit nécessaire de spécifier un PID. L'accès aux répertoires de processus tiers peut toutefois être restreint par les droits d'accès aux fichiers, les capacités Linux et l'option de montage procfs hidepid être limitées. Dans ce cas, l'absence d'informations n'est pas due à un dysfonctionnement de procfs, mais constitue une protection contre la lecture d'informations sensibles sur les processus.

Une attention particulière s'impose dans les conteneurs. Un système de fichiers procfs lié à un espace de noms PID n'affiche, pour les chemins liés aux processus, que les processus de cette vue de l'espace de noms. En revanche, les fichiers globaux du noyau tels que /proc/meminfo, /proc/stat ou /proc/diskstats peuvent continuer à refléter les valeurs de l’hôte et ne sont pas automatiquement limités aux limites du conteneur. Avant tout diagnostic, il convient donc de déterminer si la question porte sur les processus, les valeurs globales du noyau ou les ressources effectivement allouées ; les limites et l'utilisation d'un conteneur doivent en outre être prises en compte dans l'analyse cgroup2.

Lire, configurer et sécuriser sous /proc/sys

Le domaine /proc/sys Il s'agit de la vue du système de fichiers de l'interface sysctl. La lecture d'une valeur sert à des fins de diagnostic. En revanche, un accès en écriture modifie immédiatement le comportement du noyau en cours d'exécution et peut avoir une incidence sur les services, la consommation des ressources ou les fonctionnalités de sécurité. Le fait qu'une modification prenne effet sans redémarrage ne signifie pas qu'elle soit sans risque ni automatiquement permanente : la persistance dépend de la configuration système choisie.

La structure des répertoires facilite la prise en main initiale. Le répertoire /proc/sys/fs contient notamment les paramètres globaux relatifs au système de fichiers et aux descripteurs de fichiers. /proc/sys/vm regroupe les paramètres de gestion de la mémoire, tandis que /proc/sys/net contient les paramètres liés au réseau. Les sous-répertoires et clés disponibles dépendent quant à eux de la configuration du noyau et des fonctionnalités du système. Un paramètre existant ne constitue donc pas une recette universelle d’optimisation ; sa documentation et la charge de travail concrète sont déterminantes.

Un contre-exemple d'optimisation apparente est drop_caches sous /proc/sys/vm. La documentation du noyau classe cette fonction dans la catégorie « débogage et tests » et déconseille son utilisation à d’autres fins, car le vidage des caches réutilisables peut nuire aux performances. Le manque de mémoire libre n’est pas en soi une raison suffisante pour vider les caches : le noyau utilise délibérément la mémoire vive (RAM) également pour le cache de fichiers.

Toute modification doit reposer sur une raison claire et justifiée. Commence par enregistrer la valeur initiale, documente l’objectif et les effets secondaires attendus, effectue la modification de manière contrôlée, puis observe les valeurs mesurées et le comportement du service. Prévoyez à l’avance la marche arrière et n’intégrez une valeur dans une configuration permanente qu’après une vérification technique. L’article traite des principes fondamentaux supplémentaires relatifs aux paramètres et à leur gestion contrôlée Réglage du noyau dans l'hébergement Linux : aperçu des paramètres Sysctl.

Les fichiers procfs les plus importants, classés par tâche d'administration

Le choix d'un fichier procfs doit être guidé par des considérations d'administration, et non par la volonté d'obtenir une liste de répertoires aussi exhaustive que possible. Les fichiers globaux fournissent souvent des valeurs à l'échelle du noyau, les chemins de processus décrivent un processus visible individuel, et les entrées sous /proc/sys/fs fournissent des paramètres de configuration et des limites à l'échelle du système. Certaines valeurs correspondent à des états actuels, d’autres à des compteurs cumulés depuis le démarrage ou à des moyennes mobiles. Cette distinction détermine s’il suffit d’une seule lecture ou si deux points de mesure sont nécessaires.

Ce tableau est un outil d'aide à la prise en main, et non une chaîne de diagnostic. Une valeur anormale nécessite toujours une vérification indépendante : pour « Load », à l'aide des données CPU et E/S ; pour les valeurs de mémoire, à l'aide des informations « Pressure Stall » ; et pour les paramètres de processus, à l'aide du comportement du service. En particulier, /proc/diskstats et /proc/stat sont compteurs cumulatifs; leur variation par rapport à un intervalle connu est plus significative pour les taux que leur valeur absolue. Dans les conteneurs, il convient en outre de vérifier si un fichier fournit des valeurs globales du noyau ou une vue spécifique à chaque cgroup. Les sections suivantes classent donc les signaux selon la charge, la mémoire, les processus et les E/S.

Charge, CPU et mémoire : analyse combinée des signaux

Lorsque le système est lent, /proc/loadavg constitue un bon point de départ, mais ne permet pas de se faire une idée précise de l'activité du processeur. Ces trois valeurs représentent la charge moyenne des 1, 5 et 15 dernières minutes. La charge ne comprend pas seulement les unités prêtes à s'exécuter (état R), mais aussi les tâches en état d'attente non interruptible (D), par exemple lors d'opérations d'E/S. Le quatrième champ indique le nombre d'unités actuellement exécutables par rapport à l'ensemble des unités de planification existantes. Une valeur élevée Charge moyenne Cela peut donc indiquer une concurrence au niveau du processeur, des accès E/S bloqués, ou les deux.

cat /proc/loadavg
grep -E '^(cpu|intr|ctxt|processes)' /proc/stat
cat /proc/meminfo
cat /proc/pressure/memory

Les lignes relatives au processeur dans /proc/stat contiennent les temps écoulés depuis le démarrage du système en USER_HZ. Pour en déduire les taux d'utilisation, il faut comparer deux relevés ; un seul relevé n'indique que le temps cumulé. La valeur iowait ne constitue pas une mesure directe de la latence du stockage : son calcul présente des limites documentées et peut même diminuer dans certaines circonstances. Pour identifier une cause liée aux E/S, il est donc judicieux de consulter également les valeurs des périphériques et les indicateurs I/O-PSI.

Même une valeur faible pour « MemFree » ne signifie pas nécessairement que la mémoire vive est insuffisante. Linux utilise de manière ciblée la mémoire vive inutilisée pour le cache. « MemAvailable » estime la quantité de mémoire que les nouvelles applications devraient pouvoir obtenir sans recourir à la pagination, et s'avère généralement plus utile pour une première évaluation. Ce n’est que lorsque MemAvailable devient insuffisant et que des blocages de mémoire surviennent simultanément que les indices s’accumulent pour indiquer pression de stockage. Dans un conteneur, ces valeurs de mémoire globales peuvent toutefois provenir de l'hôte ; pour les ressources garanties ou limitées, la vue cgroup2 fait également autorité.

Les fichiers situés sous /proc/pressure complètent cette vue d'ensemble. Pour « memory » et « io », « some » signifie qu'au moins certaines tâches ont été bloquées pendant une partie de la fenêtre temporelle ; « full » désigne un état dans lequel toutes les tâches non inactives étaient bloquées simultanément. Les valeurs « avg10 », « avg60 » et « avg300 » se rapportent respectivement à 10, 60 et 300 secondes ; « total » correspond à un compteur cumulé des blocages. Pour le CPU, la valeur « full » au niveau du système n’est pas définie d’un point de vue sémantique et, depuis Linux 5.13, elle est renvoyée comme « null » pour des raisons de compatibilité ; elle ne doit donc pas être interprétée comme une valeur de diagnostic au niveau du système. Les PSI CPU, mémoire et E/S répondent à des questions différentes et ne doivent pas être utilisés de manière interchangeable.

Si un service réagit lentement lorsque la mémoire libre (MemFree) est faible, vérifie d'abord MemAvailable et /proc/pressure/memory. Si ces deux éléments ne présentent rien d'anormal, cela exclut une pression mémoire aiguë à l'échelle du système. Ensuite, /proc//status peut indiquer si le processus concerné présente, par exemple, une valeur VmRSS élevée, un grand nombre de threads ou un état inhabituel. Cette combinaison permet de distinguer une utilisation de la mémoire normale, mais fortement liée au cache, d’un problème nécessitant une analyse plus approfondie du processus.

Analyser les processus, les descripteurs de fichiers et les E/S sur les supports de données

Pour un exercice en toute sécurité avec un processus dont l'existence est garantie, $$ correspond au PID du shell actuel. Le fichier « status » est plus lisible que le fichier « stat », qui est orienté champs. Le nom identifie le processus, « State » son état, « PPid » le processus parent et « Threads » le nombre de threads. « VmRSS » est une approximation rapide de la mémoire résidente, dont la comptabilisation RSS est évolutive et asynchrone et peut donc être imprécise ; « VmSize », en revanche, décrit l'espace d'adressage virtuel. FDSize décrit la taille de la table des descripteurs, et non nécessairement le nombre d’entrées actuellement ouvertes. Les changements de contexte volontaires et involontaires peuvent aider à caractériser le comportement de planification, mais ne constituent pas à eux seuls une preuve d’erreur.

cat /proc/$$/status
ls -l /proc/$$/fd

Le répertoire fd contient des liens symboliques vers des fichiers ouverts, des pipes, des périphériques ou des sockets. Il permet notamment de localiser un processus qui maintient ouvert un fichier journal supprimé. On peut toutefois s'attendre à ce qu'un grand nombre de descripteurs de fichiers ouverts soit présent dans les proxys, les bases de données ou les serveurs orientés événements. Pour les vues filtrées et l'affectation entre processus, Utiliser lsof pour analyser les fichiers ouverts un complément approprié. Les lignes de commande issues de `cmdline` peuvent révéler des arguments confidentiels ; `environ` est encore plus sensible en raison de la présence éventuelle d'identifiants ou de jetons, et ne doit pas faire l'objet d'une interrogation systématique.

La commande `maps` répertorie les zones de mémoire virtuelle avec leurs autorisations, leur décalage, leur périphérique, leur inode et, le cas échéant, leur chemin d'accès. La commande `smaps` ajoute, pour chaque mappage, des valeurs de mémoire détaillées et fournit un aperçu plus précis que les informations RSS, mais plus complexe à obtenir. Ces deux fichiers sont destinés à des analyses approfondies de la mémoire : leur sortie peut être volumineuse, et l'interprétation de chaque mappage nécessite de replacer les informations dans leur contexte. Pour une première approche, la commande `status` et les fichiers de mémoire et PSI à l'échelle du système sont généralement plus efficaces.

En cas de charge élevée et d'utilisation faible du processeur, /proc/diskstats étend le diagnostic au niveau des périphériques. Ce fichier consigne des statistiques cumulées d'E/S pour chaque périphérique bloc. Pour évaluer l'activité sous forme de débit, il faut comparer deux instants. Il convient alors de distinguer clairement les disques physiques, les partitions et les périphériques virtuels ou de mappage ; les compteurs des différents niveaux ne doivent pas être additionnés sans discernement. Un descripteur de fichier ouvert par un processus ne peut pas être directement associé à un compteur de périphérique de diskstats : le système de fichiers, le cache et les couches de mappage s'interposent. En combinaison avec /proc/pressure/io, il est toutefois possible de vérifier si les blocages d’E/S observables et l’activité des périphériques coïncident dans le temps.

procfs en fonctionnement : requêtes, surveillance et protection des données

Pour obtenir des diagnostics de fonctionnement reproductibles, tu dois considérer les requêtes procfs comme des points de mesure : tu notes l'horodatage, le contexte système et la requête précise. De nombreuses valeurs sont des compteurs cumulés depuis le démarrage ; seule la différence entre deux valeurs, divisée par l'intervalle de temps, donne un taux. C'est le cas, par exemple, des compteurs issus de /proc/diskstats. Une requête isolée peut donc attester d'une activité, mais ne permet pas de quantifier de manière fiable ni le débit, ni une dégradation durable.

Un système de surveillance devrait, à intervalles réguliers, relever notamment les valeurs enregistrées dans /proc/meminfo, valeurs de l'appareil provenant de /proc/diskstats, les états des processus et du système, ainsi que les signaux d'impression lorsque le noyau le prend en charge. Il doit convertir les valeurs brutes en unités appropriées, calculer les différences pour les compteurs et enregistrer l'historique. Dans les conteneurs, il ne doit pas assimiler les valeurs procfs globales aux limites de ressources de la charge de travail : les chemins d’accès aux processus peuvent être limités à l’espace de noms PID, tandis que les valeurs de mémoire ou de périphériques reflètent en partie celles de l’hôte. Pour les limites et l’utilisation d’un groupe, des métriques cgroup2 complémentaires sont nécessaires. Seules les évolutions dans le temps permettent de définir des seuils fiables : une valeur élevée peut être normale si elle correspond à la fenêtre de charge attendue ; une augmentation soudaine par rapport à sa propre ligne de base est souvent plus significative. Les entrées procfs disponibles dépendent du noyau en cours d’exécution et de sa configuration.

Les fichiers directs et les outils se complètent. ps, top ou htop conviennent à la visualisation interactive des processus ; free, vmstat, iostat, pidstat, ss et sar Selon la configuration, ils traitent les données pour répondre à des questions spécifiques. procfs reste utile si tu souhaites examiner directement le code source du noyau ou créer un petit script facile à comprendre. Pour les alertes et la planification des capacités, les séries chronologiques constituent généralement le niveau le plus approprié.

Même dans le cas de requêtes de lecture seule, des limites de visibilité s'appliquent. Les droits d'accès, les options de montage et les espaces de noms PID peuvent masquer des données de processus ou les limiter à une vue du conteneur. À l’inverse, le fait de disposer de son propre montage /proc ne signifie pas que chaque fichier global du noyau ne contient que des données propres au conteneur. L’absence d’une entrée de processus ou une valeur globale anormalement élevée constitue donc dans un premier temps une indication qu’il convient de clarifier l’environnement d’exécution, les options de montage et le contexte cgroup.

Parcours de diagnostic pour les services lents et les goulots d'étranglement au niveau des ressources

Le dépannage commence par un symptôme, et non par une valeur isolée supposée responsable. Vérifie ensuite au moins un signal indépendant et note si l'observation concerne l'hôte, une machine virtuelle ou un conteneur. Tu évites ainsi, par exemple, de considérer trop hâtivement une charge élevée comme un problème de CPU ou un grand nombre de descripteurs ouverts comme une fuite. Les pistes suivantes constituent des premiers diagnostics à titre indicatif et ne remplacent en aucun cas les journaux spécifiques à l'application.

Lorsque la charge moyenne est élevée, commence par vérifier si ce sont les tâches en cours d'exécution ou en attente qui font grimper ce chiffre. Les indicateurs de charge représentent des moyennes sur une, cinq et quinze minutes et prennent en compte à la fois les états R et D. C'est pourquoi il convient de comparer avec prudence les champs de temps CPU avec la charge d'E/S et l'activité des périphériques. En particulier, iowait ne doit pas être interprété isolément comme une latence de mémoire.

En cas d'exécution lente et d'un MemFree faible, MemAvailable la meilleure valeur de contexte initiale. Ajoutez les PSI de mémoire et l'état du processus concerné, notamment sa valeur VmRSS, le nombre de threads et son état. En matière de mémoire et d'E/S, les PSI font la distinction entre some pour les tâches partiellement bloquées et full pour un blocage complet des tâches non-idler. L'absence de fichiers PSI peut être due à la configuration du noyau ou à l'environnement ; cela ne prouve pas l'existence d'un goulot d'étranglement.

Pour les diagnostics relatifs aux fichiers et aux processus, les droits et Espaces de noms PID limiter la pertinence des informations. Dans les conteneurs, /proc ne décrit souvent que l'environnement des processus attribués. En cas d'accès refusé ou de répertoires incomplets, vérifie donc les droits d'utilisateur, les options de montage procfs et le contexte de l'espace de noms avant de tirer une conclusion technique de l'absence de données.

Corriger les idées reçues courantes et choisir les outils adaptés

Dans l'administration Linux, quatre erreurs courantes conduisent souvent à prendre des mesures inappropriées. Peu MemFree Cela ne signifie pas automatiquement un manque de RAM, car le noyau utilise notamment la mémoire comme cache ; pour les nouvelles applications, MemAvailable constitue une estimation plus pertinente. Une charge élevée ne prouve pas une saturation du processeur, car elle inclut également les tâches en attente non interruptibles. Une part élevée d’iowait ne mesure pas la latence immédiate d’un support de données. Et procfs n’est pas identique partout : la version du noyau, la configuration, le matériel, les modules et les espaces de noms influencent les fichiers et les champs.

Choisis la méthode en fonction de la question. Pour une analyse ponctuelle des causes, on utilise procfs les données brutes directes du noyau en cours d'exécution. Pour obtenir rapidement une vue d'ensemble lisible par l'utilisateur, les outils spécialisés en ligne de commande sont généralement plus efficaces. Lorsque les tendances, les alertes ou les décisions relatives aux capacités sont importantes, vous avez besoin d’un système de surveillance qui ordonne chronologiquement les points de mesure, calcule les écarts entre les compteurs et conserve des valeurs historiques à des fins de comparaison. En cas de limites de ressources pour des services ou des conteneurs individuels, une analyse au niveau des cgroups complète la vue globale de l’hôte ; PSI peut également être disponible par cgroup si la configuration est adaptée.

Une prudence particulière s'impose dans les cas suivants : /proc/sys. La lecture d'un paramètre relève du diagnostic, tandis que sa modification influe sur le comportement du noyau. Ne modifiez une valeur que si vous en comprenez la cause, si la valeur initiale a été consignée, si les effets sont observables et s'il existe un moyen de revenir en arrière. Les répertoires fs, vm et net Ils classent les paramètres par thème, mais ne fournissent pas de recommandations universelles en matière de réglage.

L'exemple drop_caches met en évidence la différence entre intervention et optimisation : la documentation du noyau décrit cette interface comme non destructive, mais met en garde contre des problèmes de performances et ne la recommande pas comme mesure d'exploitation courante en dehors des scénarios de test ou de débogage. Une règle prudente consiste donc à : mesurer d'abord, puis procéder à une modification justifiée et limitée, observer les effets et les effets secondaires, et documenter la décision.