Débogage des goulots d’étranglement des performances
Si vous exécutez une application de calcul haute performance (HPC) sur un grand nombre de machines virtuelles (plus de 16), il est préférable de commencer par un problème plus petit sur un moins grand nombre de machines virtuelles. Ce test vérifie que votre application HPC s’exécute comme prévu.
Ne pensez pas que, parce que vous exécutez une application parallèle HPC, sa durée totale d’exécution (temps réel écoulé) va continuer à diminuer à mesure que vous l’exécutez sur davantage de machines virtuelles (avec davantage de processus parallèles). En fait, beaucoup d’applications HPC à couplage serré peuvent présenter une durée totale d’exécution plus longue quand elles sont exécutées sur d’autres machines virtuelles.
Il peut y avoir plusieurs raisons à cela. Par exemple :
Il se peut que vous ayez implémenté un algorithme parallèle de façon peu efficace.
La taille du problème, qui est la taille du modèle ou le nombre de degrés de liberté (NDOF), n’est pas assez grande. Lorsque votre application s’exécute sur davantage de processus parallèles, la quantité de calcul effectuée par chaque processus devient trop petite. En conséquence, le temps nécessaire aux communications est majoritaire dans la durée d’exécution totale. L’augmentation du temps de communication augmente la durée totale d’exécution.
Il est important de déterminer dans quelle mesure votre application HPC s’adapte à la taille du problème que vous rencontrez. Vous pouvez alors déterminer l’efficacité parallèle acceptable du point de vue du niveau de performance et des coûts.
La formule d’optimisation parallèle suivante mesure le degré d’amélioration du niveau de performance de votre application parallèle à mesure que vous ajoutez des processus parallèles :
$${\text{Optimisation parallèle}} = {\dfrac{\text{Durée totale d’exécution (1 processus)}}{\text{Durée totale d’exécution (n processus)}}}$$
La formule d’efficacité parallèle suivante illustre l’efficacité de l’utilisation des ressources de calcul au fur et à mesure que vous ajoutez des processus pour améliorer le niveau de performance de l’application parallèle :
$${\text{Efficacité parallèle}} = {\dfrac{\text{Optimisation parallèle}}{\text{N processus}}}$$
Si vous ne connaissez pas le niveau de performance de mise à l’échelle parallèle de votre application HPC à couplage serré, effectuez une étude de mise à l’échelle. En d’autres termes, exécutez votre application sur 1, 2, 4, 8, 16, etc. processus parallèles. Calculez l’accélération parallèle et l’efficacité parallèle, puis déterminez en fonction de ces résultats le nombre de processus parallèles que vous souhaitez utiliser.
Essayez de désactiver les services inutilisés qui sont susceptibles d’impacter la mise à l’échelle parallèle, comme l’agent Azure Linux. Vous pouvez réactiver les services une fois vos travaux terminés. Cette recommandation est particulièrement vraie si vous utilisez tous les cœurs disponibles et que vous effectuez une mise à l’échelle vers un grand nombre de machines virtuelles.
Pour arrêter l’agent Azure Linux, utilisez la commande suivante :
sudo system stop waagent.service
Contrôle des performances
Voici quelques contrôles d’intégrité de base qui aident à identifier les problèmes de performances potentiels.
Vérification du nombre de processus et de threads en cours d’exécution sur chaque machine virtuelle
Un moyen simple de déterminer si vous utilisez le bon nombre de processus et de threads sur chaque machine virtuelle consiste à calculer la moyenne de la charge du système sur chaque machine virtuelle avec un outil comme uptime. Le résultat doit être approximativement égal au nombre total attendu de processus et de threads sur chaque machine virtuelle. Si la moyenne de la charge enregistrée est inférieure ou supérieure au nombre total attendu de processus et de threads, cela indique un problème qui doit être résolu.
Vous devez vérifier soigneusement vos arguments pour l’interface de passage de messages (MPI) et la façon dont vous spécifiez le nombre de threads parallèles. Consultez par exemple les arguments de ligne de commande de votre application et les valeurs des variables d’environnement comme OMP_NUM_THREADS.
Vérification de l’uniformité de la répartition des processus et des threads entre tous les domaines de nœud NUMA
Si vous utilisez l’outil top ou htop, vous pouvez sélectionner la vue des domaines de nœud NUMA (Non-Uniform Memory Access) en spécifiant 2 comme paramètre de ligne de commande. (Par exemple, sur HB120_v2, vous devez normalement voir 30 domaines de nœud NUMA dans cette vue.)
Le pourcentage d’utilisation par l’utilisateur doit être réparti uniformément entre tous les domaines NUMA. Si ce n’est pas le cas, vérifiez les arguments de ligne de commande MPI et les variables d’environnement.
L’image suivante illustre la sortie de l’outil Linux top dans la vue NUMA. Dans ce cas, chaque NUMA est utilisé à 50 pour cent.
Vérification de l’état d’exécution des processus et des threads
Pour vérifier l’état d’exécution de vos processus et threads, utilisez top. Idéalement, tous les processus et threads doivent être dans un état d’exécution (R).
Si certains ou l’ensemble de vos processus et threads se trouvent dans un état de veille sans interruption (D) ou de veille (S), examinez la situation pour en comprendre la raison. Selon la conception de l’algorithme de votre application, l’état de veille peut être un comportement normal et attendu. Toutefois, cet état peut également indiquer une contrainte de ressource, comme un niveau de performance d’E/S insuffisant dû à la solution de stockage utilisée.
La formule suivante illustre l’efficacité d’exécution de l’application parallèle, si elle attend des ressources système (comme des E/S) et dans quelle mesure :
$${\text{Temps d’attente de l’application}} = {\text{Durée totale d’exécution}} – \left( {\dfrac{\text{Temps processeur total pour tous les processus parallèles}}{\text{Nombre de processus parallèles}}} \right)$$
Vérification d’une éventuelle limitation par les E/S de l’application
Quand des processus et des threads passent beaucoup de temps dans un état de veille sans interruption (D) ou de veille (S), cela peut indiquer la présence d’un goulot d’étranglement des E/S qu’il convient d’examiner. Certaines applications HPC assurent un profilage des performances dans leur sortie. Ces profils indiquent la part de temps consacrée à l’exécution des E/S et les taux d’E/S en lecture/écriture. Ces informations sont également susceptibles de pointer vers un goulot d’étranglement des E/S.
Si vous ne savez pas encore où vont vos E/S, vous pouvez aider d’outils comme iostat. Pour vérifier si vous avez un problème d’E/S, remplacez votre solution de stockage par une solution plus rapide que celle que vous avez utilisée. Ensuite, réexécutez votre application HPC. Par exemple, utilisez un disque RAM ou SSD NVMe local rapide.
Après avoir apporté cette modification, posez-vous les questions suivantes : Voyez-vous une amélioration du temps consommé par les E/S ? La durée totale d’exécution a-t-elle été améliorée ? Si oui, dans quelle mesure ?
Vérification d’une éventuelle limitation par le réseau de l’application
Déterminez la part de la durée totale d’exécution que votre application consacre à la communication entre les processus (ce qui correspond généralement à la communication MPI).
Si votre application HPC est limitée par le réseau, vérifiez que vous l’exécutez sur le réseau InfiniBand. Si une version parallèle hybride est disponible, déterminez si elle réduit le temps de communication réseau.
Si vous avez accès au code source, vérifiez s’il existe des moyens plus efficaces d’implémenter la communication. Utilisez par exemple des opérations collectives plutôt que de point à point ou testez la communication asynchrone plutôt que synchrone.