Profilage CPU avec perf : perf top, perf record -g, perf report et perf_event_paranoid

Objectif

Identifier quelle fonction consomme du CPU sur un hôte actuellement lent, d'abord avec une vue en direct, puis avec un profil enregistré que l'on peut relire.

Prérequis

L'outil perf correspondant au noyau en cours d'exécution ; soit les droits root, soit un réglage kernel.perf_event_paranoid suffisamment permissif pour un utilisateur non privilégié ; des symboles de débogage pour les binaires concernés, afin d'obtenir une sortie lisible.

Étapes

1. Vérifier le niveau de restriction actuel : sysctl kernel.perf_event_paranoid. La documentation d'administration du noyau définit précisément l'échelle : -1 n'impose aucune restriction de portée ni d'accès sur perf_events ; les valeurs >=0 autorisent la surveillance par processus et à l'échelle du système, mais excluent les tracepoints bruts ; >=1 n'autorise que la surveillance par processus ; >=2 (valeur par défaut en amont) la limite en plus aux événements de l'espace utilisateur. Les noyaux Debian et Ubuntu ajoutent au-dessus de 2 des niveaux plus stricts qui interdisent totalement l'usage non privilégié. Ce réglage ne concerne que les utilisateurs non privilégiés ; root et, depuis Linux 5.8, les processus disposant de CAP_PERFMON n'y sont pas soumis. Noter la valeur avant de la modifier, afin de pouvoir la rétablir : sudo sysctl -w kernel.perf_event_paranoid=<original>. Une modification faite avec sysctl -w ne s'applique qu'au système en cours d'exécution et disparaît au redémarrage, sauf si elle est aussi inscrite sous /etc/sysctl.d/.
2. Obtenir une vue immédiate en direct : sudo perf top, que son manuel décrit comme générant et affichant en temps réel un profil des compteurs de performance. Lire les premières lignes, classées par pourcentage d'overhead par symbole.
3. Si la colonne des symboles affiche des adresses brutes ou [unknown] au lieu de noms, le binaire ou la bibliothèque partagée concernée n'a pas de symboles de débogage ou a été strippé (ou bien le code est compilé à la volée par un JIT, ce qui requiert la prise en charge de perf-map propre au runtime) ; installer le paquet debug-info de la distribution pour ce binaire plutôt que de se fier à la liste d'adresses.
4. Pour obtenir un profil que l'on peut enregistrer, réexaminer ou transmettre à quelqu'un : sudo perf record -g -p <pid> -- sleep 30 (ou -a pour l'ensemble du système). Le manuel de perf record décrit -g comme activant l'enregistrement du graphe d'appels (chaîne de pile/backtrace) pour le noyau et l'espace utilisateur, avec fp (frame pointer) comme mode de déroulement par défaut pour l'espace utilisateur, et dwarf ou lbr sélectionnables via --call-graph lorsque les frame pointers ne sont pas fiables — ce qui est souvent le cas pour les binaires optimisés compilés sans conservation des frame pointers. La sortie est écrite dans ./perf.data (modifiable avec -o) et devient vite volumineuse avec -a, le déroulement dwarf ou de longues durées ; vérifier d'abord l'espace libre.
5. Lire les données enregistrées : sudo perf report (un fichier enregistré en tant que root n'est lisible que par root), que son manuel décrit comme affichant les informations de profil des compteurs de performance enregistrées via perf record (par défaut ./perf.data). Trier par overhead pour trouver la fonction la plus sollicitée, puis la déplier pour voir ses appelants.

Résultat attendu

Une liste classée de fonctions, et avec -g de leurs chemins d'appel, selon leur part de temps CPU, soit en direct, soit à partir d'un fichier que l'on peut rouvrir plus tard sans relancer la charge de travail.

Limites et base de vérification

Les profileurs par échantillonnage ne voient pas le code qui, par hasard, ne s'exécute à aucun instant d'échantillonnage ; les pics brefs demandent une fréquence d'échantillonnage plus élevée (-F) pour être captés. De nombreuses machines virtuelles n'exposent aucun compteur de performance matériel ; perf se rabat alors sur un événement logiciel d'horloge CPU, qui permet toujours de profiler le temps CPU mais ne peut pas fournir les compteurs de cycles ou de cache. Rétablir perf_event_paranoid à sa valeur précédente une fois le travail terminé s'il a été abaissé pour la session. La résolution des symboles exige des informations de débogage correspondantes pour chaque binaire de la pile d'appels, et pas seulement pour la frame du sommet.