{"id":20252,"date":"2026-08-02T11:49:24","date_gmt":"2026-08-02T09:49:24","guid":{"rendered":"https:\/\/webhosting.de\/linux-perf-tool-cpu-flaschenhaelse-analysieren-optimierung-serverlast-profiling\/"},"modified":"2026-08-02T11:49:24","modified_gmt":"2026-08-02T09:49:24","slug":"linux-perf-outil-analyse-des-goulots-detranglement-du-processeur-optimisation-charge-du-serveur-profilage","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/linux-perf-tool-cpu-flaschenhaelse-analysieren-optimierung-serverlast-profiling\/","title":{"rendered":"Outil Linux Perf \u2013 Analyser et r\u00e9soudre les goulots d'\u00e9tranglement du processeur"},"content":{"rendered":"<p>Gr\u00e2ce \u00e0 l'outil Linux perf, je rep\u00e8re rapidement les goulots d'\u00e9tranglement au niveau du processeur, je les classe clairement et j'en d\u00e9duis des mesures cibl\u00e9es pour y rem\u00e9dier. J'utilise les donn\u00e9es de mesure issues de <strong>Noyau<\/strong>\u2013 et l'espace utilisateur, afin de mettre en \u00e9vidence les points noirs, de r\u00e9duire les co\u00fbts et de raccourcir sensiblement les temps de r\u00e9ponse.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Les principes fondamentaux suivants guident mon approche et structurent le travail pratique avec <strong>parfait<\/strong>:<\/p>\n<ul>\n  <li><strong>Int\u00e9gr\u00e9<\/strong> Outil au niveau du noyau permettant un profilage fiable du processeur sans agents lourds<\/li>\n  <li><strong>Clairement<\/strong> S\u00e9quence de commandes : list \u2192 stat \u2192 record \u2192 report \u2192 top<\/li>\n  <li><strong>Plus faible<\/strong> Overhead, ce qui garantit une utilisation en toute s\u00e9curit\u00e9 sur les syst\u00e8mes de production<\/li>\n  <li><strong>Mesurables<\/strong> Effets : optimiser, mesurer \u00e0 nouveau, ne conserver que les modifications efficaces<\/li>\n  <li><strong>Ax\u00e9 sur la pratique<\/strong> Mod\u00e8les : \u00e9checs de cache, \u00e9checs de branche, verrous, appels syst\u00e8me<\/li>\n<\/ul>\n\n<h2>Qu'est-ce que Linux Perf ? \u2013 Et pourquoi est-ce important ?<\/h2>\n<p>Je mets <strong>parfait<\/strong> car il est directement int\u00e9gr\u00e9 au noyau Linux et fournit une interface commune pour les compteurs mat\u00e9riels, les compteurs logiciels et les points de trace. Cette proximit\u00e9 r\u00e9duit le <strong>Overhead<\/strong> et fournit des donn\u00e9es fiables, m\u00eame sous une charge \u00e9lev\u00e9e. L'architecture s\u00e9pare la logique de collecte du noyau et l'outil utilisateur, ce qui me permet de collecter des donn\u00e9es de mani\u00e8re efficace et de les analyser avec souplesse. Je peux ainsi acc\u00e9der aux compteurs r\u00e9els du processeur et surveiller des \u00e9v\u00e9nements tels que les cycles, les instructions ou les coups de cache. Je prends ainsi mes d\u00e9cisions techniques non pas \u00e0 l'instinct, mais sur la base de mesures fiables.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-analyse-cpu-beheben-7183.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>D\u00e9tecter pr\u00e9cocement les goulots d'\u00e9tranglement au niveau du processeur<\/h2>\n<p>Je r\u00e9agis rapidement, car les r\u00e9ponses lentes, la latence \u00e9lev\u00e9e et la charge persistante du processeur constituent des signes avant-coureurs \u00e9vidents et <strong>Mise \u00e0 l'\u00e9chelle<\/strong> ralentir. Des ralentissements perceptibles lors des acc\u00e8s \u00e0 la base de donn\u00e9es et des t\u00e2ches indiquent souvent des algorithmes inefficaces ou une parall\u00e9lisation incorrecte. Les processus par lots co\u00fbteux se manifestent \u00e9galement lorsque les rapports s'ex\u00e9cutent plus longtemps que pr\u00e9vu. Gr\u00e2ce \u00e0 un profilage CPU rigoureux, j'identifie ces causes plut\u00f4t que de r\u00e9server pr\u00e9cipitamment davantage de puissance de calcul. Cela r\u00e9duit la consommation de ressources et stabilise la <strong>Performance<\/strong> durable.<\/p>\n\n<h2>Le workflow avec perf : de la vue d'ensemble au point sensible<\/h2>\n<p>Je suis un ordre bien d\u00e9fini afin de passer d'une vue d'ensemble \u00e0 un goulot d'\u00e9tranglement pr\u00e9cis et <strong>Causes<\/strong> d\u00e9limiter clairement. Je commence par recueillir des indicateurs cl\u00e9s, puis je collecte des profils avec des piles d'appels et je termine par une analyse cibl\u00e9e. Pour commencer, une mesure globale suffit ; ensuite, je vise un enregistrement repr\u00e9sentatif sous charge. Pour finir, je v\u00e9rifie le comportement en temps r\u00e9el, par exemple lors d\u2019un d\u00e9ploiement. Le tableau suivant r\u00e9sume de mani\u00e8re concise les commandes, leur objectif et des exemples d\u2019appels, afin que les \u00e9tapes et <strong>Connaissances<\/strong> rester clair.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>sous-commande<\/th>\n      <th>Objectif<\/th>\n      <th>Exemple<\/th>\n      <th>Constat typique<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>liste perf<\/td>\n      <td>Afficher les \u00e9v\u00e9nements disponibles<\/td>\n      <td><code>liste perf<\/code><\/td>\n      <td>Quels sont les indicateurs pertinents pour cette question ?<\/td>\n    <\/tr>\n    <tr>\n      <td>statistique parfaite<\/td>\n      <td>Aper\u00e7u rapide des indicateurs cl\u00e9s<\/td>\n      <td><code>perf stat -a sleep 10<\/code><\/td>\n      <td>IPC, cycles, comportement du cache en un coup d'\u0153il<\/td>\n    <\/tr>\n    <tr>\n      <td>perf record<\/td>\n      <td>Enregistrer les donn\u00e9es de profilage<\/td>\n      <td><code>sudo perf record -g -F 99 .\/myapp<\/code><\/td>\n      <td>O\u00f9 le temps CPU est-il r\u00e9ellement gaspill\u00e9 ?<\/td>\n    <\/tr>\n    <tr>\n      <td>rapport de performance<\/td>\n      <td>Analyser les donn\u00e9es enregistr\u00e9es<\/td>\n      <td><code>rapport de performance<\/code><\/td>\n      <td>Points chauds par fonction et par graphe d'appels<\/td>\n    <\/tr>\n    <tr>\n      <td>perf top<\/td>\n      <td>Suivre les points chauds en temps r\u00e9el<\/td>\n      <td><code>sudo perf top<\/code><\/td>\n      <td>Visualiser imm\u00e9diatement les variations sous charge<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_perf_tool_2358.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e9lectionner des \u00e9v\u00e9nements de mani\u00e8re cibl\u00e9e : liste perf<\/h2>\n<p>Je commence avec <strong>liste perf<\/strong>, afin de v\u00e9rifier la s\u00e9lection des \u00e9v\u00e9nements pertinents pour le processeur et de cibler les mesures. Pour les probl\u00e8mes li\u00e9s \u00e0 la charge de calcul, j'observe les cycles et les instructions ; pour les probl\u00e8mes li\u00e9s \u00e0 la m\u00e9moire, je m'int\u00e9resse aux r\u00e9f\u00e9rences au cache et aux \u00e9checs de cache. Au niveau des branchements, les \u00e9checs de branchement permettent de mettre en \u00e9vidence les pr\u00e9dictions erron\u00e9es. La commande <code>liste perf<\/code> affiche les compteurs disponibles en fonction du processeur et du noyau, ce qui me permet d'effectuer une s\u00e9lection cibl\u00e9e. Ainsi, je ne mesure pas tout, mais uniquement ce qui concerne mon <strong>Question<\/strong> r\u00e9pondu.<\/p>\n\n<h2>V\u00e9rification rapide de l'\u00e9tat : bien interpr\u00e9ter les statistiques \u00ab perf stat \u00bb<\/h2>\n<p>Avec <strong>statistique parfaite<\/strong> je me fais une id\u00e9e g\u00e9n\u00e9rale avant d'approfondir le sujet. Une commande telle que <code>perf stat<\/code> fournit le nombre de cycles, d'instructions, de r\u00e9f\u00e9rences au cache, d'\u00e9checs de cache et la valeur IPC. Un IPC tr\u00e8s faible peut indiquer des temps d'attente dus \u00e0 des acc\u00e8s en m\u00e9moire, tandis qu'un IPC \u00e9lev\u00e9 sugg\u00e8re plut\u00f4t une ex\u00e9cution li\u00e9e au calcul. L'option <code>-a<\/code> Je tiens compte de cela lorsque je souhaite effectuer des mesures \u00e0 l'\u00e9chelle du syst\u00e8me, par exemple pendant les pics de trafic. Cela me permet de d\u00e9terminer rapidement si un programme sollicite fortement le processeur ou si <strong>M\u00e9moire<\/strong> en quantit\u00e9 limit\u00e9e.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cpu-bottlenecks-analysis-2745.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Analyse approfondie : \u00ab perf record \u00bb sans t\u00e2tonnements<\/h2>\n<p>Pour obtenir des informations d\u00e9taill\u00e9es, j'utilise <strong>perf record<\/strong> et capture les piles d'appels avec <code>-g<\/code>, afin de pouvoir voir les chemins d'appel complets. Je contr\u00f4le la fr\u00e9quence d'\u00e9chantillonnage \u00e0 l'aide de <code>-F<\/code>, environ 99 \u00e9chantillons par seconde pour des intervalles de temps courts et significatifs. Je choisis le profilage \u00e0 l'\u00e9chelle du syst\u00e8me lorsque la charge est r\u00e9partie sur de nombreux processus, puis je restreins l'analyse \u00e0 des services sp\u00e9cifiques. Exemple : <code>sudo perf record -F 99 -a -g -- sleep 30<\/code> \u00e9tablit un profil repr\u00e9sentatif des pics typiques. Ces donn\u00e9es rendent tangibles les points chauds invisibles et permettent de <strong>Clart\u00e9<\/strong> pour les prochaines \u00e9tapes.<\/p>\n\n<h2>Mettre en \u00e9vidence les points sensibles : perf report et perf top<\/h2>\n<p>Avec <strong>rapport de performance<\/strong> j'ouvre le fichier <code>perf.data<\/code> et je visualise la part du temps CPU consacr\u00e9e \u00e0 chaque fonction. La vue \u00ab Call Graph \u00bb r\u00e9v\u00e8le quelles cha\u00eenes d'appels contribuent \u00e0 la charge. Je marque les pourcentages \u00e9lev\u00e9s comme des points chauds et je fais soigneusement la distinction entre mon propre code, les biblioth\u00e8ques et les parties du noyau. Pour les vues en temps r\u00e9el, j'utilise <code>perf top<\/code>, afin de d\u00e9tecter imm\u00e9diatement les modifications apport\u00e9es aux d\u00e9ploiements ou aux configurations. Cela me permet de prendre des d\u00e9cisions fond\u00e9es sur les donn\u00e9es et de r\u00e9duire le <strong>Risque<\/strong> des optimisations erron\u00e9es.<\/p>\n\n<h2>Interpr\u00e9ter les mod\u00e8les de v\u00e9ritables goulots d'\u00e9tranglement<\/h2>\n<p>Dans la pratique, j'observe des sch\u00e9mas r\u00e9currents que j'explique par <strong>parfait<\/strong> que je confirme et traite rapidement. Je consid\u00e8re les points noirs n\u00e9cessitant une forte puissance de calcul comme des candidats \u00e0 un changement d'algorithme, \u00e0 la mise en cache ou \u00e0 l'utilisation de biblioth\u00e8ques plus efficaces. Les \u00e9checs de cache fr\u00e9quents indiquent des acc\u00e8s aux donn\u00e9es sous-optimaux ; j'aborde ce sujet plus en d\u00e9tail dans ma note sur <a href=\"https:\/\/webhosting.de\/fr\/cpu-cache-misses-hebergement-optimisation-des-performances-cachefix\/\">Comprendre les \u00e9checs de cache<\/a>. Un nombre \u00e9lev\u00e9 d'erreurs de branchement indique une logique trop ramifi\u00e9e, tandis qu'un temps excessif pass\u00e9 dans les fonctions de verrouillage sugg\u00e8re des conflits lors de la parall\u00e9lisation. Si les appels syst\u00e8me ou les fonctions du noyau pr\u00e9dominent, je r\u00e9duis la fr\u00e9quence des appels, je regroupe les E\/S et je renforce <strong>Mise en cache<\/strong>.<\/p>\n\n<h2>Des profils aux mesures de tuning<\/h2>\n<p>Je d\u00e9termine des optimisations concr\u00e8tes, plut\u00f4t que de r\u00e9server davantage de c\u0153urs de mani\u00e8re g\u00e9n\u00e9rale, et je valide chaque modification avec <strong>M\u00e9triques<\/strong> . Apr\u00e8s le premier profilage, j'ajuste le code, les structures de donn\u00e9es ou les configurations, puis je relance imm\u00e9diatement la mesure. Si cela ne donne aucun r\u00e9sultat, j\u2019abandonne cette approche et je teste l\u2019hypoth\u00e8se suivante. J\u2019utilise en compl\u00e9ment des profileurs sp\u00e9cifiques au langage lorsque j\u2019ai besoin d\u2019informations plus d\u00e9taill\u00e9es sur le temps d\u2019ex\u00e9cution ou le ramasse-miettes. Ce cycle ferm\u00e9 de mesure, d\u2019intervention et de v\u00e9rification permet de gagner du temps, de r\u00e9duire les co\u00fbts en euros et de renforcer la <strong>Stabilit\u00e9<\/strong>.<\/p>\n\n<h2>Perf en production : \u00e9chantillonnage, s\u00e9curit\u00e9 et conteneurs<\/h2>\n<p>En fonctionnement continu, je choisis un taux d'\u00e9chantillonnage mod\u00e9r\u00e9 afin de <strong>charge suppl\u00e9mentaire<\/strong> de les maintenir \u00e0 un niveau faible tout en obtenant des profils pertinents. Je limite les analyses \u00e0 l'\u00e9chelle du syst\u00e8me \u00e0 des plages horaires pertinentes, par exemple aux pics d'activit\u00e9, afin de ne pas surcharger inutilement le syst\u00e8me. Je d\u00e9finis clairement les droits d'acc\u00e8s, car les donn\u00e9es de performance permettent d'avoir un aper\u00e7u des processus internes. Dans les environnements utilisant des conteneurs ou KVM, je s\u00e9pare les vues h\u00f4te et invit\u00e9 et j\u2019\u00e9value ces deux perspectives. Pour les questions relatives \u00e0 la planification, je renvoie \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/linux-scheduler-cfs-alternatives-hebergement-kernelperf-boost\/\">Alternatives au SFC<\/a>, lorsque la planification par d\u00e9faut ne correspond pas \u00e0 la charge et que je souhaite tester d'autres strat\u00e9gies avant de passer \u00e0 <strong>Code<\/strong> intervienne.<\/p>\n\n<h2>Planificateur, changement de contexte et latence<\/h2>\n<p>Outre les points d'acc\u00e8s, je pr\u00eate attention aux changements de contexte, car les changements fr\u00e9quents ralentissent les threads et <strong>Latence<\/strong> augmenter. Je surveille l'affinit\u00e9 du processeur, je r\u00e9affecte les processus si n\u00e9cessaire et je r\u00e9duis la cr\u00e9ation de threads superflus. Je planifie les t\u00e2ches par lots de mani\u00e8re \u00e0 ce qu'elles n'aggravent pas les pics de charge. Cet aper\u00e7u m'aide \u00e0 \u00e9valuer de mani\u00e8re \u00e9clair\u00e9e les co\u00fbts de commutation <a href=\"https:\/\/webhosting.de\/fr\/cpu-context-switching-hosting-performance-optimization-kernel-load\/\">\u00c9valuer le changement de contexte<\/a>. Je veille ainsi \u00e0 ce que le nombre de changements reste raisonnable et \u00e0 garantir une r\u00e9partition homog\u00e8ne <strong>Taux d'occupation<\/strong>.<\/p>\n\n<h2>Choisir judicieusement l'infrastructure et la configuration d'h\u00e9bergement<\/h2>\n<p>M\u00eame un code soign\u00e9 en p\u00e2tit lorsque la <strong>Mat\u00e9riel informatique<\/strong> est sous-dimensionn\u00e9e ou que la configuration n'est pas adapt\u00e9e \u00e0 la charge. Je v\u00e9rifie les g\u00e9n\u00e9rations de processeurs, la fr\u00e9quence d'horloge, les caches et la topologie NUMA avant de proc\u00e9der \u00e0 la mise \u00e0 l'\u00e9chelle. Les r\u00e9serves c\u00f4t\u00e9 h\u00f4te permettent de faire face aux pics de charge et de r\u00e9duire les temps d'attente dans les chemins critiques. Des classes de machines uniformes facilitent la comparaison des mesures et \u00e9vitent les interpr\u00e9tations erron\u00e9es. Je combine ainsi le profilage actif avec un environnement adapt\u00e9 et r\u00e9alise chaque mois des \u00e9conomies tangibles en euros, au lieu d\u2019acheter aveugl\u00e9ment des capacit\u00e9s pour <strong>acheter<\/strong>.<\/p>\n\n<h2>Garantir la r\u00e9solution des symboles et l'int\u00e9grit\u00e9 des piles d'appels<\/h2>\n<p>D\u00e9taill\u00e9e <strong>Piles d'appels<\/strong> constituent la base de bonnes d\u00e9cisions. Je m'assure que les binaires et les biblioth\u00e8ques contiennent des informations de d\u00e9bogage (<code>-g<\/code>) et, lorsque cela est justifi\u00e9, les pointeurs de trame ne sont pas supprim\u00e9s (<code>-fno-omit-frame-pointer<\/code>). Pour les piles stables, j'utilise <code>--call-graph fp<\/code>, s'il existe des pointeurs de trame, ou <code>--call-graph dwarf<\/code>, si je pr\u00e9f\u00e8re utiliser DWARF-Unwinding : <code>perf record -g --call-graph fp -F 99 -- .\/myapp<\/code>. Sur les distributions, j'installe les fichiers appropri\u00e9s <strong>debuginfo<\/strong>-paquets, afin que <code>rapport de performance<\/code> attribue correctement les symboles. Dans les environnements de conteneurs, je veille \u00e0 ce que les symboles de d\u00e9bogage soient accessibles (par exemple via un volume) ; sinon, les rapports n'affichent que des adresses. Lorsque les biblioth\u00e8ques <em>d\u00e9pouill\u00e9<\/em> , j'utilise un processus de compilation qui stocke les informations de d\u00e9bogage s\u00e9par\u00e9ment, tout en les rendant accessibles. Ainsi, les noms de fonctions et les lignes de code source restent visibles, ce qui m'\u00e9vite d'avoir \u00e0 deviner.<\/p>\n\n<h2>Conception des mesures et reproductibilit\u00e9<\/h2>\n<p>Pour obtenir des mesures fiables, il faut un environnement propre <strong>Plan d'exp\u00e9rience<\/strong>. Je r\u00e9p\u00e8te les s\u00e9ries avec <code>perf stat -r 5 -e cycles,instructions,cache-misses --<\/code>, afin d'observer les variations, et je veille \u00e0 la coh\u00e9rence des fen\u00eatres de test (m\u00eames volumes de donn\u00e9es, m\u00eames profils de charge). La modulation de la fr\u00e9quence du processeur influe sur les indicateurs ; c'est pourquoi je documente l'\u00e9tat du r\u00e9gulateur\/du mode Turbo et je stabilise la charge \u00e0 l'aide de <code>taskset -c<\/code> sur des c\u0153urs fixes. Pour les comparaisons isol\u00e9es, j'utilise des c\u0153urs d\u00e9di\u00e9s sans charge parasite (par exemple, des processeurs isol\u00e9s). Je s\u00e9pare clairement les phases de pr\u00e9chauffage de la fen\u00eatre de mesure, afin que <strong>Caches<\/strong> et que les JIT soient stables. Pour les mesures \u00e0 l'\u00e9chelle du syst\u00e8me, j'utilise <code>-a<\/code> et d\u00e9finis la dur\u00e9e avec <code>--timeout<\/code> ou un \u00e9l\u00e9ment englobant <code>sleep<\/code>. J'\u00e9vite les interventions destructrices (telles que le vidage agressif du cache) sur les syst\u00e8mes de production et je documente chaque \u00e9tape de test afin que les r\u00e9sultats restent reproductibles.<\/p>\n\n<h2>Approfondir les analyses de la m\u00e9moire et du mod\u00e8le NUMA<\/h2>\n<p>Affiche <strong>IPC<\/strong> vers le bas et <strong>erreurs de cache<\/strong> plus haut, j'\u00e9tudie de mani\u00e8re cibl\u00e9e les comportements de la m\u00e9moire. Avec <code>record de m\u00e9moire de performance<\/code> et <code>rapport sur la m\u00e9moire de performance<\/code> Je recense les acc\u00e8s \u00e0 la m\u00e9moire et je peux attribuer des chemins co\u00fbteux (par exemple, les \u00e9checs LLC) \u00e0 des fonctions. Je tiens compte des topologies NUMA en r\u00e9duisant les acc\u00e8s \u00e0 distance (par exemple, gr\u00e2ce au thread pinning et \u00e0 l'allocation locale). Les \u00e9v\u00e9nements pertinents sont notamment :. <code>LLC-load-misses<\/code>, <code>dTLB-load-misses<\/code>, <code>erreurs de page<\/code> (mineur\/majeur) et <code>chargements en m\u00e9moire, \u00e9critures en m\u00e9moire<\/code> en fonction du processeur. Je v\u00e9rifie si les structures de donn\u00e9es favorisent l'acc\u00e8s s\u00e9quentiel et si <strong>Lignes de cache<\/strong> \u00eatre invalid\u00e9s inutilement. Des ensembles de travail trop volumineux et al\u00e9atoires indiquent des conditions d\u00e9favorables <em>structures de donn\u00e9es<\/em>; dans ce cas, le \u00ab Structure Pack \u00bb, le \u00ab Hot\/Cold Splitting \u00bb ou les algorithmes de streaming s'av\u00e8rent utiles. En ce qui concerne les bases de donn\u00e9es, je tiens compte de la taille des tampons, <strong>THP<\/strong>-Comportement et effets de pr\u00e9lecture, afin de r\u00e9duire les co\u00fbts li\u00e9s aux \u00e9checs de pr\u00e9lecture.<\/p>\n\n<h2>Analyser avec pr\u00e9cision les verrous, les planificateurs et les temps d'attente<\/h2>\n<p>Lorsque des points d'acc\u00e8s se trouvent dans <code>pthread_mutex_lock<\/code>, <code>futex<\/code> ou aboutissent \u00e0 des spinlocks, je s\u00e9pare le temps de calcul de <strong>temps d'attente<\/strong>. Avec <code>perf lock record<\/code> et <code>rapport Perf Lock<\/code> J'identifie les \u00ab locks \u00bb disput\u00e9s et leurs dur\u00e9es de maintien. <code>historique des temps de planification des performances<\/code> fournit des informations sur les d\u00e9lais de la file d'attente Runqueue, <em>pr\u00e9emption<\/em> et les cha\u00eenes de mise en veille\/r\u00e9veil ; cela me permet de d\u00e9tecter si des threads attendent une allocation de CPU au lieu d'effectuer des calculs. Un nombre \u00e9lev\u00e9 de changements de contexte associ\u00e9 \u00e0 un temps d'ex\u00e9cution court par tranche indique une parall\u00e9lisation trop fine ; j'augmente alors la taille des blocs de travail et r\u00e9duis la fr\u00e9quence de synchronisation. Pour les charges de travail gourmandes en E\/S, je r\u00e9gule les temps de blocage (par exemple, E\/S asynchrones, traitement par lots) et je s\u00e9pare les chemins de lecture\/\u00e9criture dans des threads distincts, afin que <strong>Noyaux du CPU<\/strong> Ne pas attendre les appareils lents.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpuanalysetool_office_3765.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rendre visibles les appels syst\u00e8me et la surcharge d'E\/S<\/h2>\n<p>Dominer <strong>Appels syst\u00e8me<\/strong> ou les chemins d'acc\u00e8s au noyau dans <code>rapport de performance<\/code>, j'analyse la fr\u00e9quence d'acc\u00e8s et la latence. Avec <code>trace de performance<\/code> j'observe les appels syst\u00e8me et d\u00e9tecte des sch\u00e9mas de \u00ab chatty \u00bb (par exemple, des lectures\/\u00e9critures trop petites, des <code>stat<\/code>- de nombreuses consultations <code>epoll_wait<\/code>-changement). Les mesures \u00e0 prendre sont le traitement par lots, les strat\u00e9gies \u00ab zero-copy \u00bb et l'ajustement des tampons. Fr\u00e9quentes <code>clock_gettime<\/code>- consultations ou <code>gettimeofday<\/code> Dans Hotloops, je remplace par un \u00e9chantillonnage moins fr\u00e9quent. Pour les chemins r\u00e9seau, je v\u00e9rifie si ce sont les co\u00fbts de copie ou ceux li\u00e9s \u00e0 la somme de contr\u00f4le qui pr\u00e9dominent, et j'all\u00e8ge les chemins Hotpaths en <strong>Mise en cache<\/strong> des param\u00e8tres de connexion ou le regroupement de petits paquets. L'objectif est de r\u00e9duire les transitions co\u00fbteuses entre l'utilisateur et le noyau et d'accomplir davantage de travail utile par appel syst\u00e8me.<\/p>\n\n<h2>Conteneurs, droits et s\u00e9curit\u00e9 : tout ce qu'il faut savoir<\/h2>\n<p>Sur les serveurs partag\u00e9s, les \u00e9l\u00e9ments suivants sont <strong>Droits<\/strong> et la visibilit\u00e9 sont essentielles. Je pr\u00e9sente via <code>kernel.perf_event_paranoid<\/code> et <code>kernel.kptr_restrict<\/code> d\u00e9finit des limites claires et est privil\u00e9gi\u00e9 dans les noyaux actuels <code>CAP_PERFMON<\/code> au lieu d'un acc\u00e8s complet. Dans les conteneurs, cela n\u00e9cessite <code>parfait<\/code> Configuration de l'h\u00f4te (par exemple, en transmettant les p\u00e9riph\u00e9riques `perf_event` et les capacit\u00e9s n\u00e9cessaires) ; sinon, seuls des \u00e9v\u00e9nements limit\u00e9s sont disponibles. Pour les mesures ax\u00e9es sur les conteneurs, j'applique un filtrage par cgroup afin de ne profiler que les processus pertinents et de <strong>Overhead<\/strong> r\u00e9duire. Les environnements sensibles tirent profit des journaux d'audit et des autorisations contraignantes, car les donn\u00e9es de performance peuvent en effet r\u00e9v\u00e9ler des processus internes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_perf_tool_4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Code JIT et code interpr\u00e9t\u00e9 : des piles fiables<\/h2>\n<p>\u00c0 l'adresse suivante : <strong>JIT<\/strong>-langages (par exemple JVM, .NET, JavaScript) et interpr\u00e9teurs, je veille \u00e0 une bonne r\u00e9solution 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 <code>parfait<\/code> qui nomment correctement les m\u00e9thodes. Certaines dur\u00e9es d'ex\u00e9cution g\u00e9n\u00e8rent <code>perf-PID.map<\/code>-fichiers ou <em>jitdump<\/em>- les artefacts ; je les conserve pendant la mesure et je les analyse \u00e0 l'aide de <code>rapport de performance<\/code> respectivement <code>script perf<\/code> . Pour Python et Ruby, les extensions C optimis\u00e9es constituent souvent des points critiques ; dans ce cas, les symboles de d\u00e9bogage des modules natifs fournissent des informations d\u00e9cisives. Sans piles fiables, on risque <strong>Faux points chauds<\/strong> (par exemple dans Trampolines), qui induisent en erreur les optimisations. C'est pourquoi je v\u00e9rifie avant chaque campagne si les piles sont compl\u00e8tes et stables pour la langue cible.<\/p>\n\n<h2>G\u00e9rer les programmes de longue dur\u00e9e, le multiplexage et les tampons<\/h2>\n<p>Lors de longues p\u00e9riodes d'enregistrement, j'\u00e9vite toute perte de donn\u00e9es gr\u00e2ce \u00e0 des fichiers de taille adapt\u00e9e <strong>m\u00e9moire tampon circulaire<\/strong> (<code>-m<\/code>) et des fr\u00e9quences d'\u00e9chantillonnage pr\u00e9cises. Les mesures \u00e0 haute fr\u00e9quence permettent de d\u00e9tecter des \u00e9v\u00e9nements <em>multiplexer<\/em>, ce qui complique les comparaisons ; je mesure les indicateurs importants soit par groupes, soit s\u00e9par\u00e9ment, afin d'obtenir des r\u00e9sultats fiables. Je mets en \u00e9vidence les tendances temporelles \u00e0 l'aide de <code>perf stat -I 1000 -a<\/code> visible, pour consulter les indicateurs cl\u00e9s \u00e0 la seconde pr\u00e8s, et ainsi d\u00e9tecter les pics de charge ou <em>r\u00e9gressions<\/em> apr\u00e8s les d\u00e9ploiements. Pour obtenir des chiffres comparables, j'ajuste <code>-F<\/code>\/P\u00e9riodes d'\u00e9chantillonnage et v\u00e9rifie si le PMU peut prendre en charge simultan\u00e9ment les \u00e9v\u00e9nements s\u00e9lectionn\u00e9s. Un ensemble cibl\u00e9 de compteurs par ex\u00e9cution offre une plus grande robustesse <strong>Tendances<\/strong> plut\u00f4t qu'un panier de mesure trop rempli.<\/p>\n\n<h2>Visualisation et collaboration<\/h2>\n<p>Je pr\u00e9sente les r\u00e9sultats de mani\u00e8re \u00e0 ce que les \u00e9quipes puissent rapidement s'y mettre. <code>perf report --stdio<\/code> Je l'utilise pour cr\u00e9er des instantan\u00e9s textuels dans les tickets, tandis que les vues interactives permettent de visualiser les chemins d'acc\u00e8s. Avec <code>perf annotate<\/code> Je me rends dans les fonctions suspectes et je v\u00e9rifie quelles lignes de code source cr\u00e9ent des boucles. Pour obtenir des repr\u00e9sentations synth\u00e9tiques, je g\u00e9n\u00e8re des visualisations de pile \u00e0 partir de <code>script perf<\/code>-Des donn\u00e9es qui indiquent la r\u00e9partition du temps par cha\u00eene d'appels et permettent de comparer les diff\u00e9rentes options. <code>diff. de performance<\/code> m'aide \u00e0 comparer objectivement les profils \u00ab avant\/apr\u00e8s \u00bb, ce qui me permet de <strong>Efficacit\u00e9<\/strong> des preuves concr\u00e8tes. Je dispose de profils de r\u00e9f\u00e9rence pour chaque classe de service afin de d\u00e9tecter rapidement les r\u00e9gressions et d'\u00e9tayer les discussions par des chiffres concrets.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpuflaschenhals-analyse-8472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref<\/h2>\n<p>Avec <strong>linux<\/strong> Avec perf, je travaille de mani\u00e8re cibl\u00e9e : je s\u00e9lectionne les \u00e9v\u00e9nements, j'analyse les indicateurs cl\u00e9s, je collecte des profils, j'\u00e9value les points sensibles et je mesure l'impact. Je distingue la cause du sympt\u00f4me en classant clairement les comportements de cache, les branches, les verrous et les appels syst\u00e8me. Des vues en temps r\u00e9el compl\u00e8tent l'analyse, ce qui me permet de rep\u00e9rer imm\u00e9diatement les changements et d'\u00e9viter les fausses pistes. Je garde un \u0153il sur le mat\u00e9riel et la planification afin que les donn\u00e9es de profilage restent fiables. C'est ainsi que je r\u00e9sous progressivement les goulots d'\u00e9tranglement du processeur, que je r\u00e9duis les co\u00fbts en euros et que je fournis des r\u00e9sultats coh\u00e9rents <strong>Temps de r\u00e9ponse<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Apprenez \u00e0 analyser les goulots d'\u00e9tranglement du processeur \u00e0 l'aide de l'outil Linux Perf. Nous vous expliquons \u00e9tape par \u00e9tape comment r\u00e9aliser un profilage du processeur et optimiser les performances des serveurs Linux, en mettant l'accent sur le mot-cl\u00e9 \u00ab linux perf \u00bb.<\/p>","protected":false},"author":1,"featured_media":20245,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-20252","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"113","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"linux perf","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20245","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20252","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20252"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20252\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20245"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20252"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20252"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20252"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}