perf top Linux : détecter les points chauds du processeur dans le noyau

Avec perf top Sous Linux, je peux identifier en quelques secondes les fonctions du noyau qui monopolisent actuellement le plus de temps CPU et où se situent les goulots d'étranglement. Dans ce guide, je vous montre, étape par étape, comment repérer les points chauds en temps réel, interpréter correctement les résultats et en tirer rapidement des optimisations pour le planificateur, le réseau et la mémoire.

Points centraux

Je trouve que la vue en direct de parfait C'est idéal pour bien démarrer, car cela met immédiatement en évidence les éléments qui prennent le plus de temps. Les pourcentages indiqués pour chaque symbole me permettent de savoir si le goulot d'étranglement se situe dans le Noyau ou s'il se situe dans l'espace utilisateur. À partir de schémas récurrents, je détermine si ce sont les verrous, les IRQ, le réseau ou la mémoire qui prédominent. Ensuite, je cerné le point critique à l'aide d'outils plus pointus et je vérifie les modifications directement en condition de charge. C'est ainsi que j'améliore, étape par étape, la CPU- optimiser l'utilisation des ressources et réduire durablement les latences.

• Points d'accès en direct identifier et hiérarchiser
• pourcentages interpréter correctement chaque fonction
• Objectif principal définir : IRQ, verrous, mémoire
• Flux de travail: haut → enregistrement → rapport
• Optimisations vérifier de manière ciblée

Qu'est-ce que « perf top » et à quoi ça sert ?

J'utilise perf top, afin de voir immédiatement, pendant l'exécution d'une charge, quelles fonctions consomment le plus de temps CPU. L'outil accède aux compteurs de performances matériels et m'affiche à intervalles réguliers un classement actualisé des fonctions les plus gourmandes en ressources. Selon Linux-Magazin, perf maîtrise aussi bien le profilage que le traçage, ce qui Vue en direct s'intègre parfaitement à des analyses plus approfondies. Dans le cadre d'une procédure classique, je complète cet instantané avec « perf record » et « perf report » afin d'examiner les graphes d'appels et les chemins d'accès précis. C'est ainsi que je réponds à la question centrale : où passe le CPU justement à ce moment-là – dans la pile réseau, dans le sous-système de mémoire, dans le planificateur ou dans un pilote ?

Installer et lancer perf top

Une fois l'installation effectuée à l'aide du paquet de distribution, je lance parfait En règle générale, „ top “ nécessite des droits étendus pour afficher les symboles du noyau et les événements système. Il suffit de lancer simplement « perf top » pour obtenir un premier aperçu en temps réel et identifier les fonctions dominantes. Si je souhaite me concentrer sur des processus spécifiques, j'ajoute le PID avec l'option -p ; pour certains processeurs spécifiques, j'utilise l'option -C avec une liste ou une plage. Je définis les événements avec l'option -e, par exemple « cpu-cycles », « instructions » ou « branch-misses », selon la question que je souhaite élucider. Pour obtenir des résultats reproductibles, je lance la mesure pendant une charge réelle, afin que Points chauds être clairement perceptibles et ne pas se perdre dans le bruit de fond.

Voici comment je lis correctement ce numéro

Dans cette liste, j'évalue d'abord la pourcentages par symbole, car ils reflètent les proportions de temps relatives. Des proportions élevées au niveau des fonctions système indiquent un goulot d’étranglement dans le noyau, tandis que des symboles dominants dans l’espace utilisateur renvoient plutôt à la logique de l’application. Si je constate de nombreuses routines de planification, j’en déduis qu’il y a trop de threads actifs, des affinités inappropriées ou des priorités inadaptées. Si des fonctions de mémoire apparaissent en tête, je vérifie les modèles d’allocation, les erreurs de page, la localité NUMA et les caches. Pour les chemins réseau, j’examine la répartition des IRQ, les paramètres Gro/TSO et le comportement des pilotes, car ces détails permettent de Latence influencer fortement.

Causes typiques des points chauds du noyau

De nombreux points noirs apparaissent parce que de nombreuses petites dépenses finissent par représenter une somme importante Dernier s'additionnent. Souvent, les changements de contexte excessifs, la concurrence sur les verrous et une répartition inégale des IRQ augmentent le temps CPU. De même, les structures de mémoire fragmentées, une utilisation inefficace des slabs ou une pagination constante entraînent des cycles inutiles. Si un pilote particulier attire mon attention, je le mets en corrélation avec la charge de travail, le matériel et la version afin de limiter les effets secondaires. Sur les systèmes multicœurs, je vérifie également le « false sharing », car, selon la documentation du noyau, les lignes de cache partagées peuvent rapidement entraîner une Overhead peuvent causer des soucis.

Analyse exemplaire d'un point chaud

Si je constate des proportions élevées et constantes de trafic lié au réseau sur une longue période, je commence par distinguer les types de charge : petits paquets vs gros paquets, TLS vs texte clair, nombreuses connexions vs quelques sessions de longue durée, afin de déterminer la Cause cerner le problème. Ensuite, j'approfondis l'analyse à l'aide de `perf record` et `perf report`, j'active les graphes d'appels (-g) et je compare les chemins sur plusieurs exécutions. Si, au contraire, le problème réside dans la gestion de la mémoire, je vérifie l’allocateur, les Huge Pages, les paramètres THP et l’affinité NUMA, car c’est là que des chemins inutiles peuvent rapidement apparaître. J’interprète souvent les points chauds du planificateur comme le signe d’un nombre trop élevé de threads exécutables ou d’une affectation CPU inadaptée. Je ne modifie toujours qu’un seul Paramètres par cycle, afin de pouvoir attribuer correctement l'effet.

perf top dans les environnements d'hébergement

Dans les scénarios d'hébergement, je constate souvent que de faibles coûts liés au noyau ont un impact sur la Latence de nombreux services. Les conteneurs, machines virtuelles et instances de base de données fonctionnant en parallèle font nettement pencher le profil vers le réseau, le stockage et le planificateur. Grâce à perf top, je peux déterminer si les goulots d'étranglement se situent plutôt au niveau de la gestion des IRQ, du traitement des SoftIRQ ou des chemins de verrouillage. J'intègre ensuite la version du noyau, la configuration NUMA, les affinités IRQ et les profondeurs de file d'attente dans l'analyse, car ces facteurs interagissent entre eux. Ceux qui souhaitent approfondir le sujet trouveront dans ce guide sur Analyser les goulots d'étranglement du processeur d'autres pistes pratiques que j'utilise régulièrement dans mon travail.

Guide pratique d'analyse

Je commence par un scénario de charge reproductible afin que les mesures restent comparables et Points chauds apparaissent de manière stable. Ensuite, je lance « perf top » et je note les symboles dominants sur plusieurs mises à jour. À l'aide de « perf record/report », je synthétise cet instantané en une vue claire des graphes d'appel, afin d'identifier le chemin menant au point coûteux. Ensuite, je ne modifie de manière ciblée qu’un seul paramètre, par exemple une affinité d’IRQ ou une profondeur de file d’attente, puis je procède à une nouvelle mesure. Ce n’est que lorsque l’effet est clair que je passe à l’étape suivante Étape et je consigne ces informations en vue des prochaines fenêtres de maintenance.

Quand d'autres outils sont-ils indiqués ?

Pour obtenir une vue d'ensemble historique, des graphiques d'appels plus détaillés ou des chaînes d'événements spécifiques, j'utilise parfait record/report, ftrace ou eBPF. Les points de trace m'aident à mettre en lumière des chemins de manière ciblée, tandis que les programmes BPF me permettent d'obtenir des métriques flexibles. Lorsque je souhaite examiner plus en détail les chemins du noyau, Outils d'analyse eBPF des informations précieuses directement sur le lieu même de l'événement. Pour les problèmes de cache et de partage, perf-c2c et pahole s'avèrent utiles dès lors que le point sensible est clairement identifié. Je passe ainsi de l'analyse en temps réel à l'identification de la cause, sans me perdre dans des éléments non pertinents Détails de perdre.

Options d'échantillonnage et filtres : mise en pratique

Je passe le Échantillonnage- Je m'adapte à la situation plutôt que de tout mesurer de manière globale. En cas de pics sporadiques, j'augmente la fréquence d'échantillonnage et je raccourcis les intervalles d'affichage afin de capturer les pics éphémères. Pour me concentrer sur un processus, je définis -p sur le PID concerné ; pour me concentrer sur le CPU, je définis -C sur les cœurs les plus sollicités. Avec -e, je contrôle l’événement, par exemple « cpu-cycles » pour un profilage global ou « cache-misses » si je soupçonne un problème de gestion de la mémoire. J’utilise les graphes d’appels (-g) dès que j’ai localisé approximativement un point chaud et que le Cause qu'il souhaite trouver dans la pile.

Le tableau suivant présente des combinaisons pratiques de commutateurs que j'utilise souvent au quotidien, ainsi que les utilisations typiques de chaque option :

Option	Effet	Utilisation
-p PID	Limite la mesure à un seul processus	Spécifiques à l'application Points chauds délimiter
-C Liste des processeurs	Priorité à certains domaines clés	Vérifier la répartition NUMA/IRQ
-e événement	Sélectionne un événement matériel ou logiciel	cycles, instructions, échecs de cache
-g	Active l'échantillonnage du graphe d'appels	Des sentiers coûteux dans le Pile reconnaître
–noyau/–utilisateur	Filtre au niveau du noyau ou de l'espace utilisateur	Isoler la source du temps CPU
–trier	Trié par symbole, DSO, dso:symbol	Lisibilité de la Classement augmentent

Je teste toujours brièvement les configurations avant de lancer des mesures plus longues, afin que les Afficher reste stable et ne provoque aucun effet secondaire. C'est justement lorsque la fréquence d'échantillonnage est élevée que je fais attention à la surcharge, afin de ne pas solliciter inutilement le système. Sur les hôtes de conteneurs, je vérifie en outre si les limites des espaces de noms et des cgroups restreignent la visibilité. Pour garantir la reproductibilité des tests de performance, je documente tous les paramètres, y compris les versions du noyau et des pilotes. Cette rigueur me fait gagner beaucoup de temps par la suite Temps pour classer les changements.

Interprétation des sous-systèmes : réseau, mémoire, planificateur

Lorsque les chemins réseau sont en haut de la liste, je vérifie d'abord les affinités IRQ, le RSS (Receive-Side-Scaling) et les déchargements tels que GRO/TSO, car ces paramètres permettent d'optimiser la Débit- Modifier l'équilibre de latence. Lorsque les fonctions de mémoire présentent des anomalies, j'examine les modèles d'allocation, les Huge Pages, les statistiques Slab et les taux de Page Fault. J'associe souvent la charge du planificateur à un nombre excessif de threads, à un manque d'affinité CPU ou à une priorisation inéquitable. Pour les événements spécifiques du noyau, j’ajoute des points de trace ou j’utilise bpftrace dans l'hébergement, afin de confirmer des hypothèses. Je recoupe ainsi les observations en direct de Perf Top avec des points de mesure plus profonds, ce qui me permet d'arriver plus rapidement à la Cause.

Conditions requises et visibilité des symboles

Avec cela, perf top Lorsque je résous tous les symboles pertinents du noyau, je veille à deux choses : les droits d'accès appropriés et la disponibilité des informations sur les symboles. Sur les systèmes de production, kernel.perf_event_paranoid souvent définie à un niveau élevé. Pour obtenir des vues approfondies du noyau, je réduis temporairement cette valeur ou je travaille en tant qu’utilisateur root avec les droits nécessaires (CAP_PERFMON/CAP_SYS_ADMIN). Si les adresses du noyau sont masquées (kptr_restrict), je vois généralement quand même les noms, mais pas les adresses brutes – cela me suffit pour établir les priorités. Pour l'espace utilisateur, j'installe les paquets d'informations de débogage correspondants afin que `perf top` affiche les noms de fonctions plutôt que les décalages. Cela évite les conjectures et permet d'identifier plus rapidement la cause du problème.

Pourcentages et pièges liés à l'échantillonnage

J'interprète les pourcentages de la liste comme suit : parts relatives des échantillons mesurés, et non comme une charge CPU exacte dans le domaine temporel. Si je sélectionne plusieurs événements, il est possible que Multiplexage agir : Perf répartit les contre-attaques dans le temps et normalise l'affichage. Pour obtenir un historique clair, je commence par effectuer une mesure globale en cycles CPU ou en instructions, puis j'ajoute les événements spécifiques par la suite. Je détecte les pics de courte durée en utilisant une fréquence plus élevée (-F) et des intervalles plus courts ; pour les systèmes peu sollicités, la fréquence par défaut suffit. Je note également que Idle- les variations de phase et de fréquence (Turbo, Governor) peuvent fausser la perception. C'est pourquoi j'uniformise les réglages de cadence et d'énergie pour les mesures comparatives.

Les graphes d'appel en détail

Une fois que j'ai identifié un point noir, j'affine mon analyse à l'aide des graphes d'appels. Avec -g et grâce à une méthode d'unwinding adaptée, j'obtiens le chemin d'accès à l'endroit coûteux. Les pointeurs de trame ou l'unwinding DWARF me fournissent des piles stables ; lorsque c'est possible, j'utilise des tampons de retour matériels (LBR) pour obtenir des chaînes très précises. Je n'augmente les tampons mmap que dans la mesure nécessaire pour limiter la surcharge. Si la pile comporte de nombreuses fonctions auxiliaires, je veille à y compris vs. exclusif Coûts : ce qui est déterminant, c'est de savoir si la fonction elle-même est coûteuse ou si elle ne sert principalement que de voie de transit. Cette distinction me fait souvent gagner des heures dans la recherche des causes.

Travailler dans des conteneurs et des machines virtuelles

Dans les environnements de conteneurs, je vérifie si ma vue sur cgroups et que les espaces de noms sont corrects. Je concentre les mesures sur les PID et les processeurs pertinents, afin que les « voisins bruyants » ne faussent pas le tableau. Pour les machines virtuelles, je vérifie si le PMU virtuel est activé ; sinon, il me manque des événements matériels précis et je ne vois principalement que des signaux logiciels. Je reconnais souvent les hôtes KVM grâce à des icônes autour de kvm_vcpu ou vmx/svm. Dans ce genre de situation, je sépare clairement les analyses de l'hôte et celles de l'invité afin de ne pas confondre cause et effet.

Modèles identifiables et hypothèses rapides

Au quotidien, certaines habitudes ont fait leurs preuves, que je vérifie immédiatement :

• Concurrence de Lock: Plongée queued_spin_lock_slowpath ou mutex_spin_on_owner Au niveau supérieur, les structures de données sont trop grossières ou les files d'attente de travail trop restreintes. Je réduis les conflits grâce au sharding, à une granularité de verrouillage plus fine ou à une modification de la taille des lots.
• Impression du planificateur: Se multiplient schedule(), choisir_la_prochaine_tâche_équitable ou les chemins de réveil, j'ajuste le nombre de threads, les affinités et les priorités. Il suffit souvent de “ calmer ” les threads « bavards » ou de définir clairement les paramètres du processeur.
• SoftIRQ réseau: pics à net_rx_action, napi_poll ou les déchargements de somme de contrôle indiquent des tempêtes de paquets ou une répartition sous-optimale des RSS et des IRQ. J'affecte les IRQ aux cœurs appropriés et j'ajuste les paramètres GRO/TSO pour obtenir le profil débit/latence souhaité.
• Chemins d'accès aux fichiers: Beaucoup de temps à do_page_fault, copy_user_* ou les fonctions « Slab » me permettent de vérifier les modèles d'allocation, les THP/Huge Pages et la localité NUMA. Un mauvais placement peut ici coûter un nombre considérable de cycles sans que l'on s'en aperçoive.
• RCU et temporisateurs: Dominer rcu_core ou les callbacks de la minuterie, je repense les stratégies de polling et de traitement par lots de mes services afin d'assurer un fonctionnement plus fluide du système.

Approfondir ses connaissances en matière de rigueur de mesure et de reproductibilité

Pour obtenir des exécutions parfaitement comparables, je maintiens les facteurs environnementaux constants : régulateur du processeur, états Turbo, tâches en arrière-plan, voire la température ambiante pour les nœuds denses. J'affecte les charges de test à des cœurs définis et, si nécessaire, j'isole les processeurs surchauffés afin que les décisions du planificateur restent stables. Je documente toutes les modifications, y compris les versions du noyau, des pilotes et du micrologiciel. Pour les réglages plus risqués, je prévois des points de retour et effectue de nouvelles mesures immédiatement après l'intervention. J'obtiens ainsi des résultats fiables Avant/Après-Une histoire que je peux encore comprendre, même des mois plus tard.

Astuces pratiques : les commandes que j'utilise souvent

Selon la question, j'utilise des formules concises :

• Évaluation approfondie sous contrainte: perf top -e cpu-cycles –kernel –user
  Aperçu rapide permettant de savoir si c'est le noyau ou l'espace utilisateur qui mène la danse.
• Focus sur les processus avec Callgraph: perf top -p PID -g –kernel –user
  Affiche-moi les chemins d'accès en temps réel de l'application concernée, sans bruit de fond du système.
• Zoom sur le processeur: perf top -C 2-5 -e cycles CPU -g
  Permet de remédier aux points chauds NUMA ou IRQ lorsque seuls quelques cœurs sont “ en surchauffe ”.
• Soupçon de stockage: perf top -e cache-misses -e cycles -g –kernel
  Affiche les chemins de mémoire par rapport aux cycles.
• Fixer les pointes instables: perf top -F 999 -I 1000 -e cycles
  Une fréquence plus élevée et des intervalles d'affichage plus courts permettent de détecter les pics de courte durée.

Aides à l'interprétation pour des sous-systèmes spécifiques

À l'adresse suivante : Réseau Outre les chemins NAPI et RX/TX, je surveille également les parts TLS/crypto, qui peuvent devenir prédominantes en cas de trafic important de handshakes. Je vérifie si le « zero-copy » ou le « coalescing » s’avèrent efficaces et si les segments volumineux (TSO/GSO) dépassent mes budgets de latence. Dans le Mémoire- Dans ce domaine, je me réfère à THP : est-ce que cela allège ma charge, ou est-ce que les événements de fractionnement/fusion créent des interférences ? Dans le cas de Stockage j'interprète blk_mq-Les symboles et les chemins io_uring comme indication de la profondeur des files d'attente et des stratégies de fusion. Lors de la planificateur J'associe les avalanches “ wakeup ” à des chaînes « lock » ou « IO » et j'équilibre les chemins en utilisant la contre-pression plutôt que « davantage de threads ».

Les limites de Perf Top et à quel moment je change de stratégie

Parce que perf top Comme il s'agit d'une approche basée sur l'échantillonnage, je préfère les images moyennes aux événements individuels. Pour les chaînes d'exécution déterministes, je passe aux tracepoints, à ftrace ou à eBPF afin de mettre en évidence des causalités précises. Si j'ai besoin d'une quantification exacte (par exemple, le nombre d'instructions par requête), je combine ces méthodes avec statistique parfaite ou des analyses hors ligne à partir de « perf record/report ». Si je tombe sur des piles peu claires (symboles manquants, déroulement incorrect), je commence par régler le problème de visibilité – sinon, ce serait comme tâtonner dans le brouillard.

En bref

Avec perf top Je repère en temps réel où le processeur perd du temps dans le noyau et quels symboles je dois examiner en priorité. À partir des pourcentages, des schémas récurrents et de la distinction entre l'espace noyau et l'espace utilisateur, je détermine les prochaines étapes à suivre de manière ciblée. Je synthétise ensuite ces informations à l’aide de `perf record/report`, je vérifie les changements sous charge et je documente ma chaîne de mesure. Dans les environnements d’hébergement, cette approche s’avère particulièrement payante, car de nombreux services et conteneurs en tirent profit dès que les chemins du noyau fonctionnent plus efficacement. Ceux qui maîtrisent ce processus gagnent des jours de diagnostic et réduisent Latence et permet d'obtenir des temps de réponse nettement plus stables sous une charge réelle.