Passer au contenu 
Grâce à l'outil Linux perf, je repère rapidement les goulots d'étranglement au niveau du processeur, je les classe clairement et j'en déduis des mesures ciblées pour y remédier. J'utilise les données de mesure issues de Noyau– et l'espace utilisateur, afin de mettre en évidence les points noirs, de réduire les coûts et de raccourcir sensiblement les temps de réponse.
Points centraux
Les principes fondamentaux suivants guident mon approche et structurent le travail pratique avec parfait:
- Intégré Outil au niveau du noyau permettant un profilage fiable du processeur sans agents lourds
- Clairement Séquence de commandes : list → stat → record → report → top
- Plus faible Overhead, ce qui garantit une utilisation en toute sécurité sur les systèmes de production
- Mesurables Effets : optimiser, mesurer à nouveau, ne conserver que les modifications efficaces
- Axé sur la pratique Modèles : échecs de cache, échecs de branche, verrous, appels système
Qu'est-ce que Linux Perf ? – Et pourquoi est-ce important ?
Je mets parfait car il est directement intégré au noyau Linux et fournit une interface commune pour les compteurs matériels, les compteurs logiciels et les points de trace. Cette proximité réduit le Overhead et fournit des données fiables, même sous une charge élevée. L'architecture sépare la logique de collecte du noyau et l'outil utilisateur, ce qui me permet de collecter des données de manière efficace et de les analyser avec souplesse. Je peux ainsi accéder aux compteurs réels du processeur et surveiller des événements tels que les cycles, les instructions ou les coups de cache. Je prends ainsi mes décisions techniques non pas à l'instinct, mais sur la base de mesures fiables.
Détecter précocement les goulots d'étranglement au niveau du processeur
Je réagis rapidement, car les réponses lentes, la latence élevée et la charge persistante du processeur constituent des signes avant-coureurs évidents et Mise à l'échelle ralentir. Des ralentissements perceptibles lors des accès à la base de données et des tâches indiquent souvent des algorithmes inefficaces ou une parallélisation incorrecte. Les processus par lots coûteux se manifestent également lorsque les rapports s'exécutent plus longtemps que prévu. Grâce à un profilage CPU rigoureux, j'identifie ces causes plutôt que de réserver précipitamment davantage de puissance de calcul. Cela réduit la consommation de ressources et stabilise la Performance durable.
Le workflow avec perf : de la vue d'ensemble au point sensible
Je suis un ordre bien défini afin de passer d'une vue d'ensemble à un goulot d'étranglement précis et Causes délimiter clairement. Je commence par recueillir des indicateurs clés, puis je collecte des profils avec des piles d'appels et je termine par une analyse ciblée. Pour commencer, une mesure globale suffit ; ensuite, je vise un enregistrement représentatif sous charge. Pour finir, je vérifie le comportement en temps réel, par exemple lors d’un déploiement. Le tableau suivant résume de manière concise les commandes, leur objectif et des exemples d’appels, afin que les étapes et Connaissances rester clair.
| sous-commande | Objectif | Exemple | Constat typique |
|---|---|---|---|
| liste perf | Afficher les événements disponibles | liste perf | Quels sont les indicateurs pertinents pour cette question ? |
| statistique parfaite | Aperçu rapide des indicateurs clés | perf stat -a sleep 10 | IPC, cycles, comportement du cache en un coup d'œil |
| perf record | Enregistrer les données de profilage | sudo perf record -g -F 99 ./myapp | Où le temps CPU est-il réellement gaspillé ? |
| rapport de performance | Analyser les données enregistrées | rapport de performance | Points chauds par fonction et par graphe d'appels |
| perf top | Suivre les points chauds en temps réel | sudo perf top | Visualiser immédiatement les variations sous charge |
Sélectionner des événements de manière ciblée : liste perf
Je commence avec liste perf, afin de vérifier la sélection des événements pertinents pour le processeur et de cibler les mesures. Pour les problèmes liés à la charge de calcul, j'observe les cycles et les instructions ; pour les problèmes liés à la mémoire, je m'intéresse aux références au cache et aux échecs de cache. Au niveau des branchements, les échecs de branchement permettent de mettre en évidence les prédictions erronées. La commande liste perf affiche les compteurs disponibles en fonction du processeur et du noyau, ce qui me permet d'effectuer une sélection ciblée. Ainsi, je ne mesure pas tout, mais uniquement ce qui concerne mon Question répondu.
Vérification rapide de l'état : bien interpréter les statistiques « perf stat »
Avec statistique parfaite je me fais une idée générale avant d'approfondir le sujet. Une commande telle que perf stat fournit le nombre de cycles, d'instructions, de références au cache, d'échecs de cache et la valeur IPC. Un IPC très faible peut indiquer des temps d'attente dus à des accès en mémoire, tandis qu'un IPC élevé suggère plutôt une exécution liée au calcul. L'option -a Je tiens compte de cela lorsque je souhaite effectuer des mesures à l'échelle du système, par exemple pendant les pics de trafic. Cela me permet de déterminer rapidement si un programme sollicite fortement le processeur ou si Mémoire en quantité limitée.
Analyse approfondie : « perf record » sans tâtonnements
Pour obtenir des informations détaillées, j'utilise perf record et capture les piles d'appels avec -g, afin de pouvoir voir les chemins d'appel complets. Je contrôle la fréquence d'échantillonnage à l'aide de -F, environ 99 échantillons par seconde pour des intervalles de temps courts et significatifs. Je choisis le profilage à l'échelle du système lorsque la charge est répartie sur de nombreux processus, puis je restreins l'analyse à des services spécifiques. Exemple : sudo perf record -F 99 -a -g -- sleep 30 établit un profil représentatif des pics typiques. Ces données rendent tangibles les points chauds invisibles et permettent de Clarté pour les prochaines étapes.
Mettre en évidence les points sensibles : perf report et perf top
Avec rapport de performance j'ouvre le fichier perf.data et je visualise la part du temps CPU consacrée à chaque fonction. La vue « Call Graph » révèle quelles chaînes d'appels contribuent à la charge. Je marque les pourcentages élevés comme des points chauds et je fais soigneusement la distinction entre mon propre code, les bibliothèques et les parties du noyau. Pour les vues en temps réel, j'utilise perf top, afin de détecter immédiatement les modifications apportées aux déploiements ou aux configurations. Cela me permet de prendre des décisions fondées sur les données et de réduire le Risque des optimisations erronées.
Interpréter les modèles de véritables goulots d'étranglement
Dans la pratique, j'observe des schémas récurrents que j'explique par parfait que je confirme et traite rapidement. Je considère les points noirs nécessitant une forte puissance de calcul comme des candidats à un changement d'algorithme, à la mise en cache ou à l'utilisation de bibliothèques plus efficaces. Les échecs de cache fréquents indiquent des accès aux données sous-optimaux ; j'aborde ce sujet plus en détail dans ma note sur Comprendre les échecs de cache. Un nombre élevé d'erreurs de branchement indique une logique trop ramifiée, tandis qu'un temps excessif passé dans les fonctions de verrouillage suggère des conflits lors de la parallélisation. Si les appels système ou les fonctions du noyau prédominent, je réduis la fréquence des appels, je regroupe les E/S et je renforce Mise en cache.
Des profils aux mesures de tuning
Je détermine des optimisations concrètes, plutôt que de réserver davantage de cœurs de manière générale, et je valide chaque modification avec Métriques . Après le premier profilage, j'ajuste le code, les structures de données ou les configurations, puis je relance immédiatement la mesure. Si cela ne donne aucun résultat, j’abandonne cette approche et je teste l’hypothèse suivante. J’utilise en complément des profileurs spécifiques au langage lorsque j’ai besoin d’informations plus détaillées sur le temps d’exécution ou le ramasse-miettes. Ce cycle fermé de mesure, d’intervention et de vérification permet de gagner du temps, de réduire les coûts en euros et de renforcer la Stabilité.
Perf en production : échantillonnage, sécurité et conteneurs
En fonctionnement continu, je choisis un taux d'échantillonnage modéré afin de charge supplémentaire de les maintenir à un niveau faible tout en obtenant des profils pertinents. Je limite les analyses à l'échelle du système à des plages horaires pertinentes, par exemple aux pics d'activité, afin de ne pas surcharger inutilement le système. Je définis clairement les droits d'accès, car les données de performance permettent d'avoir un aperçu des processus internes. Dans les environnements utilisant des conteneurs ou KVM, je sépare les vues hôte et invité et j’évalue ces deux perspectives. Pour les questions relatives à la planification, je renvoie à Alternatives au SFC, lorsque la planification par défaut ne correspond pas à la charge et que je souhaite tester d'autres stratégies avant de passer à Code intervienne.
Planificateur, changement de contexte et latence
Outre les points d'accès, je prête attention aux changements de contexte, car les changements fréquents ralentissent les threads et Latence augmenter. Je surveille l'affinité du processeur, je réaffecte les processus si nécessaire et je réduis la création de threads superflus. Je planifie les tâches par lots de manière à ce qu'elles n'aggravent pas les pics de charge. Cet aperçu m'aide à évaluer de manière éclairée les coûts de commutation Évaluer le changement de contexte. Je veille ainsi à ce que le nombre de changements reste raisonnable et à garantir une répartition homogène Taux d'occupation.
Choisir judicieusement l'infrastructure et la configuration d'hébergement
Même un code soigné en pâtit lorsque la Matériel informatique est sous-dimensionnée ou que la configuration n'est pas adaptée à la charge. Je vérifie les générations de processeurs, la fréquence d'horloge, les caches et la topologie NUMA avant de procéder à la mise à l'échelle. Les réserves côté hôte permettent de faire face aux pics de charge et de réduire les temps d'attente dans les chemins critiques. Des classes de machines uniformes facilitent la comparaison des mesures et évitent les interprétations erronées. Je combine ainsi le profilage actif avec un environnement adapté et réalise chaque mois des économies tangibles en euros, au lieu d’acheter aveuglément des capacités pour acheter.
Garantir la résolution des symboles et l'intégrité des piles d'appels
Détaillée Piles d'appels constituent la base de bonnes décisions. Je m'assure que les binaires et les bibliothèques contiennent des informations de débogage (-g) et, lorsque cela est justifié, les pointeurs de trame ne sont pas supprimés (-fno-omit-frame-pointer). Pour les piles stables, j'utilise --call-graph fp, s'il existe des pointeurs de trame, ou --call-graph dwarf, si je préfère utiliser DWARF-Unwinding : perf record -g --call-graph fp -F 99 -- ./myapp. Sur les distributions, j'installe les fichiers appropriés debuginfo-paquets, afin que rapport de performance attribue correctement les symboles. Dans les environnements de conteneurs, je veille à ce que les symboles de débogage soient accessibles (par exemple via un volume) ; sinon, les rapports n'affichent que des adresses. Lorsque les bibliothèques dépouillé , j'utilise un processus de compilation qui stocke les informations de débogage séparément, tout en les rendant accessibles. Ainsi, les noms de fonctions et les lignes de code source restent visibles, ce qui m'évite d'avoir à deviner.
Conception des mesures et reproductibilité
Pour obtenir des mesures fiables, il faut un environnement propre Plan d'expérience. Je répète les séries avec perf stat -r 5 -e cycles,instructions,cache-misses --, afin d'observer les variations, et je veille à la cohérence des fenêtres de test (mêmes volumes de données, mêmes profils de charge). La modulation de la fréquence du processeur influe sur les indicateurs ; c'est pourquoi je documente l'état du régulateur/du mode Turbo et je stabilise la charge à l'aide de taskset -c sur des cœurs fixes. Pour les comparaisons isolées, j'utilise des cœurs dédiés sans charge parasite (par exemple, des processeurs isolés). Je sépare clairement les phases de préchauffage de la fenêtre de mesure, afin que Caches et que les JIT soient stables. Pour les mesures à l'échelle du système, j'utilise -a et définis la durée avec --timeout ou un élément englobant sleep. J'évite les interventions destructrices (telles que le vidage agressif du cache) sur les systèmes de production et je documente chaque étape de test afin que les résultats restent reproductibles.
Approfondir les analyses de la mémoire et du modèle NUMA
Affiche IPC vers le bas et erreurs de cache plus haut, j'étudie de manière ciblée les comportements de la mémoire. Avec record de mémoire de performance et rapport sur la mémoire de performance Je recense les accès à la mémoire et je peux attribuer des chemins coûteux (par exemple, les échecs LLC) à des fonctions. Je tiens compte des topologies NUMA en réduisant les accès à distance (par exemple, grâce au thread pinning et à l'allocation locale). Les événements pertinents sont notamment :. LLC-load-misses, dTLB-load-misses, erreurs de page (mineur/majeur) et chargements en mémoire, écritures en mémoire en fonction du processeur. Je vérifie si les structures de données favorisent l'accès séquentiel et si Lignes de cache être invalidés inutilement. Des ensembles de travail trop volumineux et aléatoires indiquent des conditions défavorables structures de données; dans ce cas, le « Structure Pack », le « Hot/Cold Splitting » ou les algorithmes de streaming s'avèrent utiles. En ce qui concerne les bases de données, je tiens compte de la taille des tampons, THP-Comportement et effets de prélecture, afin de réduire les coûts liés aux échecs de prélecture.
Analyser avec précision les verrous, les planificateurs et les temps d'attente
Lorsque des points d'accès se trouvent dans pthread_mutex_lock, futex ou aboutissent à des spinlocks, je sépare le temps de calcul de temps d'attente. Avec perf lock record et rapport Perf Lock J'identifie les « locks » disputés et leurs durées de maintien. historique des temps de planification des performances fournit des informations sur les délais de la file d'attente Runqueue, préemption et les chaînes de mise en veille/réveil ; cela me permet de détecter si des threads attendent une allocation de CPU au lieu d'effectuer des calculs. Un nombre élevé de changements de contexte associé à un temps d'exécution court par tranche indique une parallélisation trop fine ; j'augmente alors la taille des blocs de travail et réduis la fréquence de synchronisation. Pour les charges de travail gourmandes en E/S, je régule les temps de blocage (par exemple, E/S asynchrones, traitement par lots) et je sépare les chemins de lecture/écriture dans des threads distincts, afin que Noyaux du CPU Ne pas attendre les appareils lents.
Rendre visibles les appels système et la surcharge d'E/S
Dominer Appels système ou les chemins d'accès au noyau dans rapport de performance, j'analyse la fréquence d'accès et la latence. Avec trace de performance j'observe les appels système et détecte des schémas de « chatty » (par exemple, des lectures/écritures trop petites, des stat- de nombreuses consultations epoll_wait-changement). Les mesures à prendre sont le traitement par lots, les stratégies « zero-copy » et l'ajustement des tampons. Fréquentes clock_gettime- consultations ou gettimeofday Dans Hotloops, je remplace par un échantillonnage moins fréquent. Pour les chemins réseau, je vérifie si ce sont les coûts de copie ou ceux liés à la somme de contrôle qui prédominent, et j'allège les chemins Hotpaths en Mise en cache des paramètres de connexion ou le regroupement de petits paquets. L'objectif est de réduire les transitions coûteuses entre l'utilisateur et le noyau et d'accomplir davantage de travail utile par appel système.
Conteneurs, droits et sécurité : tout ce qu'il faut savoir
Sur les serveurs partagés, les éléments suivants sont Droits et la visibilité sont essentielles. Je présente via kernel.perf_event_paranoid et kernel.kptr_restrict définit des limites claires et est privilégié dans les noyaux actuels CAP_PERFMON au lieu d'un accès complet. Dans les conteneurs, cela nécessite parfait Configuration de l'hôte (par exemple, en transmettant les périphériques `perf_event` et les capacités nécessaires) ; sinon, seuls des événements limités sont disponibles. Pour les mesures axées sur les conteneurs, j'applique un filtrage par cgroup afin de ne profiler que les processus pertinents et de Overhead réduire. Les environnements sensibles tirent profit des journaux d'audit et des autorisations contraignantes, car les données de performance peuvent en effet révéler des processus internes.
Code JIT et code interprété : des piles fiables
À l'adresse suivante : JIT-langages (par exemple JVM, .NET, JavaScript) et interpréteurs, je veille à une bonne résolution des symboles. Pour Java, je sauvegarde les pointeurs de trame dans les hotspots, j'active les informations JIT et j'utilise des cartes JIT afin que parfait qui nomment correctement les méthodes. Certaines durées d'exécution génèrent perf-PID.map-fichiers ou jitdump- les artefacts ; je les conserve pendant la mesure et je les analyse à l'aide de rapport de performance respectivement script perf . Pour Python et Ruby, les extensions C optimisées constituent souvent des points critiques ; dans ce cas, les symboles de débogage des modules natifs fournissent des informations décisives. Sans piles fiables, on risque Faux points chauds (par exemple dans Trampolines), qui induisent en erreur les optimisations. C'est pourquoi je vérifie avant chaque campagne si les piles sont complètes et stables pour la langue cible.
Gérer les programmes de longue durée, le multiplexage et les tampons
Lors de longues périodes d'enregistrement, j'évite toute perte de données grâce à des fichiers de taille adaptée mémoire tampon circulaire (-m) et des fréquences d'échantillonnage précises. Les mesures à haute fréquence permettent de détecter des événements multiplexer, ce qui complique les comparaisons ; je mesure les indicateurs importants soit par groupes, soit séparément, afin d'obtenir des résultats fiables. Je mets en évidence les tendances temporelles à l'aide de perf stat -I 1000 -a visible, pour consulter les indicateurs clés à la seconde près, et ainsi détecter les pics de charge ou régressions après les déploiements. Pour obtenir des chiffres comparables, j'ajuste -F/Périodes d'échantillonnage et vérifie si le PMU peut prendre en charge simultanément les événements sélectionnés. Un ensemble ciblé de compteurs par exécution offre une plus grande robustesse Tendances plutôt qu'un panier de mesure trop rempli.
Visualisation et collaboration
Je présente les résultats de manière à ce que les équipes puissent rapidement s'y mettre. perf report --stdio Je l'utilise pour créer des instantanés textuels dans les tickets, tandis que les vues interactives permettent de visualiser les chemins d'accès. Avec perf annotate Je me rends dans les fonctions suspectes et je vérifie quelles lignes de code source créent des boucles. Pour obtenir des représentations synthétiques, je génère des visualisations de pile à partir de script perf-Des données qui indiquent la répartition du temps par chaîne d'appels et permettent de comparer les différentes options. diff. de performance m'aide à comparer objectivement les profils « avant/après », ce qui me permet de Efficacité des preuves concrètes. Je dispose de profils de référence pour chaque classe de service afin de détecter rapidement les régressions et d'étayer les discussions par des chiffres concrets.
En bref
Avec linux Avec perf, je travaille de manière ciblée : je sélectionne les événements, j'analyse les indicateurs clés, je collecte des profils, j'évalue les points sensibles et je mesure l'impact. Je distingue la cause du symptôme en classant clairement les comportements de cache, les branches, les verrous et les appels système. Des vues en temps réel complètent l'analyse, ce qui me permet de repérer immédiatement les changements et d'éviter les fausses pistes. Je garde un œil sur le matériel et la planification afin que les données de profilage restent fiables. C'est ainsi que je résous progressivement les goulots d'étranglement du processeur, que je réduis les coûts en euros et que je fournis des résultats cohérents Temps de réponse.
