URL: https://linuxfr.org/news/profileurs-memoire-malt-et-numaprof
Title: Profileurs mémoire MALT et NUMAPROF
Authors: Sébastien Valat
Pierre Jarillon, Davy Defaud, claudex et palm123
Date: 2018年08月31日T22:48:02+02:00
License: CC By-SA
Tags: hpc, numa et fortran
Score: 48
Outils de profilage
===================
En [[calcul à haute performance]] — HPC (_High Performance Computing_) —, les problèmes liés à la mémoire deviennent de plus en plus critiques, qu’il s’agisse du contrôle de la consommation mémoire des applications, de la limitation des interactions avec le système d’exploitation (trop nombreuses allocations, trop petites allocations...) et de choix de placement ([[NUMA]]) ; et relativement peu d’outils libres permettent de profiler les applications sur ce terrain. Deux outils récemment mis en ligne apportent une part de réponse à ces questions.
La suite de l’article présentera MALT et NUMAPROF plus en détails...
----
[GitHub NUMAPROF](https://github.com/memtt/numaprof)
[GitHub MALT](https://github.com/memtt/malt)
[Site Web](https://memtt.github.io/)
----
MALT
====
MALT (_MALloc Tracker_) a été développé lors d’un post‐doc comme un outil de profilage d’allocation mémoire. L’outil reprend la sémantique efficace du couple valgrind‐kcachegrind, mais appliquée au suivi des allocations mémoire d’une application C, C++ ou Fortran.
Fournissant une interface plus complète que kcachegrind, MALT fournit une interface graphique Web exportée par un petit serveur en [[Node.js]]. Cette approche a un double intérêt :
1. rapidité de développement pour un rendu agréable, en utilisant les bibliothèques JavaScript Angular, Bootstrap, D3JS ;
2. sur une grappe de serveurs distante, l’interface est rendue localement en se connectant au serveur distant par un _ssh-port-forward_, ce qui évite les ralentissements gênants et habituels liés à un _X forward_ d’une interface Qt ou GTK ;
3. possibilité de travailler à plusieurs sur le même profil.
L’outil fournit entre autres :
- un résumé global sur la consommation de l’application ;
- des annotation du source code pour les différentes métriques ;
- des compteurs pour les tailles minimum et maximum d’allocation, le nombre d’allocations et la durée de vie ;
- des graphiques temporels ;
- la distribution de la taille des objets alloués ;
- la distribution des allocations sur les différents fils d’exécution.
Exemple d’interface :
NUMAPROF
========
En [[calcul à haute performance]] et pour un certain nombre de serveurs, il est désormais courant de rencontrer des architectures dites [NUMA](https://fr.wikipedia.org/wiki/Non_uniform_memory_access "Non‐Uniform Memory Access") (_Non‐Uniform Memory Access_). Autrement dit, avoir plusieurs processeurs sur la même carte mère, chacun attaché à ses propres bancs mémoire. La mémoire distante étant accessible de manière transparente, mais avec un surcoût. Cette topologie apparait même désormais à l’intérieur des processeurs eux‐mêmes, si l’on considère la gamme Xeon Phi d’Intel et certains processeurs AMD pour les serveurs.
Rappelons que sur les systèmes modernes, la mémoire vue par un programme est une mémoire dite virtuelle que le système d’exploitation est en charge, en collaboration avec le processeur, de faire correspondre à la mémoire physique. Cette correspondance entre les deux espaces est faite à l’aide du mécanisme de pagination consistant à découper ces deux espaces en pages (en général, 4 Kio ou 2 Mio sur les architectures x86 et x86-64).
Lorsqu’un segment est alloué par une application, il est initialement purement virtuel, le système d’exploitation autorisant cet espace mémoire, mais n’y projetant pas immédiatement de page physique. Ce n’est que lors du premier accès (dit « _first touch_ ») que le système d’exploitation sera notifié et attachera une page à l’endroit touché.
Ce moment est critique sur architecture NUMA, car c’est à ce moment que le système d’exploitation va décider (en fonction de la position courante du fil d’exécution effectuant l’accès) sur quel nœud NUMA placer la page et donc les données. Le problème pour le développeur étant que cette association se fait de manière implicite par la première lecture‐écriture, et non par un appel explicite de fonction. Ceci conduit, dans de nombreuses applications, à des problèmes ignorés et de mauvaises correspondances difficiles à vérifier.
C’est dans ce cadre qu’a été développé NUMAPROF, en se basant sur _pintool_ pour suivre tous les accès mémoire de l’application et reporter les correspondances NUMA. L’outil reprend une interface très similaire à MALT et fournit entre autres :
- une annotation du source code ;
- des métriques donnant le nombre d’accès distants, locaux, MCDRAM (pour les Intel _Knight Landing_), accès non liés (« bindés ») ;
- une distribution sur les fils d’exécution ;
- une matrice d’accès permettant de rapidement évaluer le comportement global de l’application.
Attention, l’outil ne prend pour l’instant en charge que les architectures x86-64.
Exemple d’interface :
Sources
=======
Les deux outils sont libres et disponibles sur GitHub. Vous trouverez les sources, captures d’écran, documentations et liens vers des outils similaires sur : .