Autres commandes

J’ai exclu de ce TP un certain nombre de commandes de la suite perf, principalement parce qu’elles me semblaient moins utiles dans la vie de tous les jours ou parce qu’il était difficile pour X ou Y raison d’en enseigner le maniement sur srv-calcul-ambulant.

Dans cette annexe, nous allons cependant faire quand même un point rapide sur ces commandes, leur fonction, et la cause de leur non-inclusion dans le TP.

Gestion des symboles de déboguage

Nous l’avons vu au cours du TP, perf fait un usage assez intensif des symboles de déboguage. Ce qui pose quelques problèmes en pratique.

Tout d’abord, sous les distributions Linux actuelles, les symboles de déboguage des bibliothèques systèmes sont stockés dans des fichiers distincts des bibliothèques elle-mêmes. Cela permet aux personnes qui n’ont pas besoin de ces symboles de ne pas les installer dans un premier temps, quitte à revenir sur cette décision plus tard. Mais cela signifie aussi qu’un outil comme perf ou GDB qui utilise des symboles de déboguage doit, à chaque fois qu’il en a besoin, faire une série de requêtes dans un certain nombre de répertoires dans l’espoir de les trouver, ce qui peut devenir coûteux quand on s’y réfère souvent.

Pour éviter ces requêtes à répétition, perf garde en cache l’emplacement où il a trouvé les symboles de déboguage de tous les binaires ELF qu’il a analysés, indexés par le build-id, un identifiant interne partagé par le binaire ELF et ses informations de déboguage. Vous pouvez gérer ce cache au moyen de la commande perf buildid-cache.

Un problème connexe est la répétabilité des analyses effectués avec perf sur une machine différente de celle où des mesures ont été acquises. Cette répétabilité est déjà, à la base, restreinte par l’interopérabilité limitée qui existe entre différentes versions de perf. Mais quand les informations de déboguage entrent dans l’équation, le problème devient encore plus complexe, puisqu’il est difficile de répliquer de façon exacte les versions de binaires existant sur une machine A sur une autre machine B en utilisant uniquement le gestionnaire de paquets.

perf propose donc la commande perf archive, qui combine un fichier perf.data avec les différents symboles de déboguage dont il dépend dans une archive pour faciliter la répétition d’analyses de performance sur une machine distante.

Dans une logique similaire, nous pouvons aussi mentionner la commande perf kallsyms, qui permet de connaître l’emplacement en mémoire virtuelle où sont chargés les différents symboles du noyau, ce qui est utilisé en interne par perf report lors de l’analyse de l’utilisation CPU du noyau.

Manipulation de fichiers `perf.data`

Quelques outils permettent de manipuler les fichiers perf.data produits par perf record :

perf data a vocation a devenir un outil généraliste pour manipuler ces fichiers, mais à l’heure où sont écrites ces lignes il ne peut que les convertir au format Common Trace Format.
perf diff permet de calculer les différences entre les profils de deux fichiers perf.data. Sur le principe, ça pourrait être très intéressant dans une activité d’optimisation de performances. Mais pour l’instant, cet outil ne travaille qu’en terme de fonctions, (overhead “Self” de perf report) et pas de graphes d’appels (overhead “Children”). L’information qu’il affiche est donc généralement trop bas niveau pour être utilisable.
perf evlist permet de savoir quels événements ont été enregistrés dans un fichier.
perf inject permet de partir d’un fichier perf.data et en tirer un second fichier perf.data contenant quelques données supplémentaires : build-ids des fichiers profilés, événements artificiels indiquant pendant combien de temps un thread s’est assoupi… Pour l’instant, ses fonctionnalités sont très spécifiques à des cas d’utilisation bien particuliers.

Commandes incompatibles avec `srv-calcul-ambulant`

Les commandes perf suivantes sont intéressantes dans l’absolu, mais ne peuvent pas être présentées dans le cadre d’un TP sur srv-calcul-ambulant car elles sont incompatibles avec certaines des décisions de conception de ce serveur :

perf ftrace propose un mécanisme alternatif de suivi des événements système basé sur l’infrastructure ftrace. Cette commande est hardcodée pour n’être utilisable par root, et n’est donc pas utilisable par des utilisateurs non administrateurs du serveur.
perf lock permet d’analyser l’utilisation des mutex, mais utilise pour ça des tracepoints qui ne sont pas activés sur les noyaux fournis par la distribution openSUSE que nous utilisons.