Face aux limitations sémantiques des outils de visualisation de performance, ce chapitre applique la technique d'agrégation présentée dans la deuxième partie de cette thèse. L'objectif visé est la production de représentations macroscopiques pertinentes sur le plan syntaxique et sémantique pour l'ana-lyse des applications parallèles. En particulier, nous cherchons à détecter les anomalies présentes à diérents niveaux dans les traces d'exécution. Nous procédons pour cela à l'agrégation spatiale des traces et à leur visualisation via des treemaps multirésolution. L'approche est validée sur trois cas d'étude. Les deux premiers sont issus de traces d'exécution réelles (section 7.3). Le troisième, destiné à montrer l'ecacité de l'approche à grande échelle, s'in-téresse à une trace engendrée de manière articielle (section 7.4).
7.2.1 Applications et traces analysées
Les deux cas d'étude présentés dans la section suivante s'intéressent aux per-formances d'une application parallèle composées de tâches de calcul. Celles-ci sont réparties et exécutées sur la plate-forme Grid'5000, infrastructure d'expérimentation destinée à la recherche en informatique distribuée3. Cette plate-forme de calcul réunit actuellement plus de 2 200 processeurs, totali-sant près de 7 900 c÷urs, reliés par un réseau haute performance distribué géographiquement sur 9 sites en France et 2 sites à l'étranger. La répartition des tâches de calcul sur une plate-forme de cette envergure nécessite l'utilisa-tion d'algorithmes de synchronisal'utilisa-tion distribués et dynamiques, chargés de contrôler la concurrence et d'optimiser la performance du système en équi-librant les charges de travail entre les processus. L'étude de ces algorithmes non-déterministes constitue un champ de recherche à part entière, reposant notamment sur l'analyse empirique de leurs résultats.
Dénition 7.1. Nous notons Ωp l'ensemble des processus exécutés sur la plate-forme pour une application donnée. Il s'agit du niveau micro-scopique de l'analyse spatiale, détaillant l'exécution de chacune des res-sources de calcul.
3Voir le Wiki dédiéhttps://www.grid5000.fr/et l'article présentant la plate-forme
106 CHAPITRE 7. VISUALISATION DE PERFORMANCE L'algorithme de répartition analysé dans la suite de ce chapitre repose sur KAAPI4, une librairie pour la synchronisation des tâches et des ux de données dans les systèmes distribués. L'algorithme est d'abord chargé de dis-tribuer les tâches de calcul entre les processus, puis d'équilibrer les charges de travail de manière dynamique lors de l'exécution. Pour procéder à l'éva-luation de cet algorithme, nous récupérons des traces d'exécution contenant, pour chaque processus, le temps consacré au calcul lui-même (état Run) et le temps durant lequel le processus, devenu inactif, tente de décharger les autres processus par le biais de requêtes de vol de travail (état Steal).
Les temps passés par les processus dans chacun des deux états Run et Steal constituent les attributs du niveau de représentation microscopique. Ils sont co-dépendants dans la mesure où, sur la période analysée, les proces-sus sont toujours dans un état ou dans l'autre. Ainsi, pour chaque procesproces-sus, la somme de Run et de Steal est égale au temps d'exécution total du pro-cessus. Le cas d'exécution idéal correspond à une faible valeur de l'attribut Steal pour tous les processus, indiquant que la grande majorité du temps d'exécution est dédiée au calcul. Nous sommes donc plus particulièrement intéressés par la visualisation de l'attribut Steal.
Dénition 7.2. Nous notons vSteal l'application de Ωp dans R indi-quant le temps passé par chaque processus dans l'état Steal5. Il s'agit de l'attribut soumis à l'analyse.
7.2.2 Organisation hiérarchique de la plate-forme
La topologie du réseau de communication liant entre elles les ressources de la plate-forme Grid'5000 aecte l'exécution des applications. En eet, du fait de la distribution matérielle et géographique du système, les ressources de calcul sont plus ou moins proches en temps de communication : deux processus auront plus de facilité à communiquer s'ils appartiennent, dans l'ordre, à la même machine, deux machines au même cluster, à deux clusters du même site, etc. Ces propriétés du réseau sont donc liées à l'organisation hiérarchique de la plate-forme, étagée en niveaux de ressources : le niveau des
4 Kernel for Adaptative, Asynchronous Parallel and Interactive programming, voir
le site dédié http://kaapi.gforge.inria.fr/ et l'article présentant la libraire en
dé-tail [GBP07].
5 En terme de dénombrement (cf. sous-section 3.2.1), l'attribut vSteal peut être
in-terprété comme la quantité de cycles d'horloge consacrés au vol de travail. Ces unités atomiques étant de l'ordre de la nanoseconde, nous préférons une interprétation continue
processus, où les tâches sont eectivement exécutées, le niveau des machines, coordonnant plusieurs processus, le niveau des clusters, regroupant plusieurs machines, le niveau des sites, etc.
L'algorithme de répartition doit prendre en compte la topologie du réseau pour optimiser les performances du système. Nous faisons donc l'hypothèse que cette topologie permet d'expliquer au moins en partie le comporte-ment des processus. En ce sens, deux processus relativecomporte-ment proches dans le réseau de communication sont supposés avoir une exécution similaire vis-à-vis de l'algorithme de répartition. En eet, dans la mesure où ils appartiennent au même contexte d'exécution, ils devraient avoir à peu près la même charge de travail. Les comportements hétérogènes témoignent alors d'une mauvaise répartition des charges, révélant ainsi d'éventuelles imperfections de l'algo-rithme. L'organisation hiérarchique sert donc de base sémantique pour l'agré-gation de données (cf. section 5.2). Les agrégats représentent des groupes de ressources cohérentes vis-à-vis de la disposition syntaxique du système.
Dénition 7.3. Nous notons TpΩpq l'ensemble des parties deΩp corres-pondant aux processus regroupés par niveaux de ressources. X PTpΩpq peut désigner un processus (singleton), l'ensemble des processus coor-donnés par une machine, l'ensemble des processus présents au sein d'un cluster, etc. Ces ensembles respectent la structure syntaxique du système et leur comportement est en partie expliqué par la nature du réseau. Ils constituent donc les parties admissibles de l'agrégation spatiale.
Nous notons PTpΩpq l'ensemble des partitions admissibles selon cette organisation hiérarchique. Il s'agit des représentations macroscopiques pertinentes pour l'analyse spatiale de l'algorithme de répartition.
7.2.3 Outils de visualisation et représentations treemap
Nous utilisons les outils open-source PajéNG6 et Viva7, au sein desquels nous avons implémenté les mesures de qualité et l'algorithme des partitions optimales. Ces outils ont été choisis pour leur implémentation des représen-tations treemap, permettant de visualiser les traces qui nous intéressent.
Les treemaps sont particulièrement bien adaptées à la visualisation des
6 Outil d'analyse implémentant des techniques de visualisation classiques. Voir
https://github.com/schnorr/pajeng/et l'article sur l'outil de visualisation Pajé dont PajéNG est une ré-implémentation en C++ [CSB00].
7 Outil d'analyse reposant sur PajéNG et implémentant des techniques de
visualisa-tion alternatives telles que les treemaps [JS91, SHN12] et les graphes de répartivisualisa-tion des
108 CHAPITRE 7. VISUALISATION DE PERFORMANCE
(a) 188 machines (b) 9 clusters
(c) 5 sites (d) Agrégation totale
Figure 7.3 Représentation treemap d'une application exécutée sur la plate-forme Grid'5000 au niveau des machines (hosts), des clusters et des sites (extrait de [SHN12])
hiérarchies [Shn92]. Comme le montre la gure 7.3, les diérents agrégats y sont représentés par des boîtes imbriquées . La treemap 7.3a permet de visualiser l'exécution au niveau microscopique : chaque rectangle représente un processus x P Ωp et les couleurs à l'intérieur des rectangles représentent les attributs des processus. Ici, il s'agit du temps passé dans l'état Run (vRunpxq en vert) et du temps passé dans l'état Steal (vStealpxq en rouge). Ainsi, plus un processus est rouge, plus il a été en situation de vol de travail lors de l'exécution. Les trois autres treemaps sont engendrées par agrégation de la treemap microscopique à diérents niveaux de la hiérarchie. Les sur-faces correspondent à des ensembles de processus X P TpΩpq. Les valeurs microscopiques des attributs y sont additionnées, indiquant la somme du temps passé dans chacun des états par les processus sous-jacents (vRunpXq etvStealpXq). La treemap 7.3d représente une seule valeur des attributs : la somme du temps passé par tous les processus dans chacun des états (vRunpΩpq etvStealpΩpq).
Viva autorise deux procédures d'agrégation diérentes : (1) une agré-gation par niveau, comme illustré dans la gure 7.3 et (2) une agréagré-gation manuelle, où les temps d'exécution sont agrégés sur demande de l'utilisateur pour chaque élément de la visualisation. Ainsi, il est possible de produire des représentations multirésolution en choisissant à la main les machines,
les clusters ou les sites à agréger. An de contrôler et d'automatiser cette procédure d'agrégation, nous avons implémenté les mesures de qualité et l'algorithme des partitions optimales (cf. chapitres 4 et 6) au sein du logiciel. Ainsi, Viva fournit maintenant des indications sur la qualité des agrégats constitués. L'utilisateur peut alors distinguer les agrégats utiles à l'analyse (suppression d'information redondante) et ceux qui peuvent lui nuire (perte d'information). De plus, Viva propose à l'utilisateur une nouvelle procédure d'agrégation automatisée, fournissant des représentations multirésolution en fonction du coecient de compromis spécié en entrée (cf. sous-section 4.3.3).
7.2.4 Mesures de qualité
À chaque partition de l'ensemble des processusX PPTpΩpq, admissible selon l'organisation hiérarchique de la plate-forme, correspond une et une seule treemap. An de quantier la perte d'information vis-à-vis de la treemap microscopique, et d'ainsi mesurer l'hétérogénéité des agrégats, nous utilisons la divergence de Kullback-Leibler DpXq (cf. sous-section 4.3.2).
Il est également nécessaire de quantier la complexité d'une représen-tation treemap pour appliquer l'algorithme des partitions hiérarchiques op-timales. Dans le contexte de la visualisation de traces, nous devons trou-ver un critère graphique pour exprimer cette complexité. La granularité des treemaps peut être simplement dénie par le nombre d'agrégats qui y sont visualisés. En eet, le calcul d'une treemap et son rendu graphique dépendent linéairement du nombre de rectangles représentés [Shn92]. Nous utilisons donc la taille de la représentation TpXq pour quantier la com-plexité (cf. sous-section 4.3.1). L'utilisation d'autres mesures de comcom-plexité, telles que l'entropie de Shannon (cf. annexe A), n'est pas adaptée aux re-présentations treemap dans la mesure où nous ne visualisons pas les unités atomiques sous-jacentes (cycles d'horloge dédiés au vol de travail), mais une agrégation préliminaire de ces unités (temps passé dans l'état Steal).
Ainsi, la mesure de qualité combinée que l'on cherche à optimiser pour donner les meilleures représentations treemap des traces d'exécution ana-lysées est la suivante (cf. sous-section 4.3.3) :
CQLαpXq α ∆QpXq
∆QpPJpΩpqq p1αq
DpXq DpPJpΩpqq
où α P r0,1s est le coecient de compromis spécié par l'utilisateur en fonction de la quantité de détails attendus.
110 CHAPITRE 7. VISUALISATION DE PERFORMANCE Dans les sections suivantes, nous montrons que les représentations engen-drées par notre méthode d'agrégation permettent de détecter à moindre coût les comportements irréguliers au sein de l'exécution et de les rapporter à la disposition syntaxique du système observé (section 7.3). L'approche répond alors aux dés de la visualisation de performance en passant à l'échelle du million de processus (section 7.4).
7.3 Détection d'anomalies dans les traces