Profilage d'applications distribuées avec Perf

Comme de nombreux développeurs, j'ai été dans des situations où j'avais besoin de prendre une application existante et de la rendre plus rapide, essentiellement en supprimant le code lent et en le remplaçant par du code rapide. Je sais maintenant suivre une règle simple lorsqu'il s'agit d'optimiser le code :

Quel que soit le code qui, selon moi, ralentit l'application, c'est là que je devrais regarder en dernier.

Le profilage est un métier qui vous fait accepter très rapidement les limites de votre intuition. J'ai réalisé très tôt que j'avais besoin de mesures dures et froides pour me dire quelles parties de mon code devaient être optimisées. Heureusement, il existe une pléthore d'outils de profilage disponibles qui peuvent mesurer à peu près tout ce qui concerne l'exécution de votre code.

Cependant, les outils ne facilitent pas nécessairement le profilage. L'interprétation des mesures peut être délicate et les variables doivent être étroitement contrôlées lors de la conduite d'expériences. En particulier, les applications multithread et distribuées sont difficiles à profiler.

Quiconque a déjà eu à déboguer une condition de concurrence connaîtra à quel point le comportement des applications multithread est sensible au temps. Le profilage d'applications multithread présente des défis similaires, car le timing devient un facteur important dans la mesure.

Les profileurs comme callgrind ralentissent considérablement votre programme et ont donc un impact sur le timing. Un exemple qui montre une limitation de ces profileurs est la contention mutex. Votre application peut s'exécuter lentement car un mutex est fortement utilisé, ce qui oblige votre code à passer beaucoup de temps dans les fonctions de verrouillage. Un outil comme callgrind ne le révélerait pas, car il compte les instructions , pas le temps.

Il existe une autre classe de profileurs qui effectuent un « profilage statistique ». Ces profileurs vous permettent d'exécuter votre programme comme vous le feriez normalement, tout en prenant des instantanés périodiques de l'endroit où l'application passe son temps. Ces profileurs doivent fonctionner pendant un certain temps pour produire des résultats précis, mais peuvent le faire avec un impact minimal sur le timing. Cela en fait un excellent choix pour le profilage d'applications multithread et/ou distribuées !

Je voulais partager un flux de travail de profilage à l'aide de l'outil Linux perf, que j'ai trouvé particulièrement utile car il me permet d'identifier rapidement les « points chauds » de performances. J'utiliserai l'exemple c/hello_dynamic de RTI Connext 5.3.0 comme cible pour mesurer les performances.

Tout d'abord, assurez-vous que perf est installé sur votre machine Linux. Sur Ubuntu, j'ai dû lancer cette commande pour installer perf sur ma machine :

sudo apt-get install linux-tools-common linux-tools-3.13.0-107-generic

Ensuite, vous devez télécharger un projet GitHub capable de convertir la sortie des performances en ce qu'on appelle un « FlameGraph », qui est une représentation visuelle des données de profilage collectées. Exécutez cette commande à partir d'un emplacement facile d'accès (comme votre répertoire personnel) :

git clone https://github.com/brendangregg/FlameGraph

Accédez maintenant à l'exemple hello_dynamic dans le dossier rti_workspace/examples/c. Construisez le code avec ces commandes (assurez-vous que NDDSHOME est défini sur l'installation RTI Connext) :

objs/x64Linux3gcc4.8.2/Bonjour sous &
 sudo perf record -g objs/x64Linux3gcc4.8.2/Hello pub

~/FlameGraph/flamegraph.pl out.perf-folded> perf.svg