Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Essayer d'exécuter une tâche
La section suivante propose des solutions de dépannage possibles si vous rencontrez des problèmes lors de l'exécution d'une tâche.
## `srun`la tâche interactive échoue avec une erreur `srun: error: fwd_tree_thread: can't find address for , check slurm.conf`
+ **Pourquoi a-t-il échoué ?**
Vous avez exécuté la `srun` commande pour soumettre une tâche, puis vous avez augmenté la taille d'une file d'attente en utilisant la `pcluster update-cluster` commande sans redémarrer les Slurm démons une fois la mise à jour terminée.
Slurmorganise Slurm les démons dans une arborescence afin d'optimiser la communication. Cette hiérarchie n'est mise à jour que lorsque les démons démarrent.
Supposons que vous `srun` lanciez une tâche, puis que vous exécutiez la `pcluster update-cluster` commande pour augmenter la taille de la file d'attente. De nouveaux nœuds de calcul sont lancés dans le cadre de la mise à jour. Ensuite, place votre tâche en Slurm file d'attente sur l'un des nouveaux nœuds de calcul. Dans ce cas, les Slurm daemons et les `srun` don't détectent les nouveaux nœuds de calcul. `srun`renvoie une erreur car il ne détecte pas les nouveaux nœuds.
+ **Comment résoudre le problème ?**
Redémarrez les Slurm démons sur tous les nœuds de calcul, puis utilisez-les `srun` pour soumettre votre tâche. Vous pouvez planifier le redémarrage Slurm des démons en exécutant la `scontrol reboot` commande qui redémarre les nœuds de calcul. Pour plus d'informations, consultez [scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot) dans la Slurm documentation. Vous pouvez également redémarrer manuellement les Slurm démons sur les nœuds de calcul en demandant le redémarrage des services correspondants`systemd`.
## Job bloqué dans son `CF` état avec `squeue` la commande
Cela peut être dû au démarrage des nœuds dynamiques. Pour de plus amples informations, veuillez consulter [Observation des erreurs lors de l'initialisation des nœuds de calcul](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Exécuter des travaux à grande échelle et voir `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`
Avec un système de fichiers en réseau, lorsque les limites du réseau sont atteintes, le temps I/O d'attente augmente également. Cela peut entraîner des blocages logiciels, car le réseau est utilisé pour écrire des données à la fois pour le réseau et I/O pour les métriques.
Avec les instances de 5e génération, nous utilisons le pilote ENA pour exposer les compteurs de paquets. Ces compteurs comptent les paquets façonnés AWS lorsque le réseau atteint les limites de bande passante de l'instance. Vous pouvez vérifier ces compteurs pour voir s'ils sont supérieurs à 0. Si tel est le cas, cela signifie que vous avez dépassé vos limites de bande passante. Vous pouvez consulter ces compteurs en courant`ethtool -S eth0 | grep exceeded`.
Le dépassement des limites du réseau est souvent dû à la prise en charge d'un trop grand nombre de connexions NFS. C'est l'une des premières choses à vérifier lorsque vous atteignez ou dépassez les limites du réseau.
Par exemple, le résultat suivant montre les packages abandonnés :
```
$ ethtool -S eth0 | grep exceeded
bw_in_allowance_exceeded: 38750610
bw_out_allowance_exceeded: 1165693
pps_allowance_exceeded: 103
conntrack_allowance_exceeded: 0
linklocal_allowance_exceeded: 0
```
Pour éviter de recevoir ce message, envisagez de remplacer le type d'instance du nœud principal par un type d'instance plus performant. Envisagez de déplacer votre stockage de données vers des systèmes de fichiers de stockage partagés qui ne sont pas exportés sous forme de partage NFS, tels qu'Amazon EFS ou Amazon FSx. Pour plus d'informations, consultez [Stockage partagé](shared-storage-quotas-integration-v3.md) les [meilleures pratiques](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) sur le AWS ParallelCluster Wiki sur GitHub.
## Exécution d'une tâche MPI
### Activation du mode de débogage
Pour activer le mode de débogage d'OpenMPI, [voir Quelles sont les commandes d'Open MPI qui facilitent](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls) le débogage ?
Pour activer le mode de débogage IntelMPI, consultez la section [Autres](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html) variables d'environnement.
### Voir `MPI_ERRORS_ARE_FATAL` et `OPAL ERROR` intégrer le résultat du travail
Ces codes d'erreur proviennent de la couche MPI de votre application. Pour savoir comment obtenir les journaux de débogage MPI à partir de votre application, consultez. [Activation du mode de débogage](#run-job-mpi-enable-v3)
Cette erreur peut être due au fait que votre application a été compilée pour une implémentation MPI spécifique, telle qu'OpenMPI, et que vous essayez de l'exécuter avec une autre implémentation MPI, telle qu'IntelMPI. Assurez-vous de compiler et d'exécuter votre application avec la même implémentation MPI.
### Utilisation `mpirun` avec DNS géré désactivé
Pour les clusters créés avec [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Dns/[DisableManagedDns](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns)et [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) définis sur`true`, le nom du Slurm nœud n'est pas résolu par le DNS](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns). Slurmpeut démarrer des processus MPI lorsqu'ils `nodenames` ne sont pas activés et si la tâche MPI est exécutée dans un contexte. Slurm Nous vous recommandons de suivre les instructions du [guide de l'utilisateur Slurm MPI](https://slurm.schedmd.com/mpi_guide.html) pour exécuter des tâches MPI avec. Slurm