Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Sto cercando di eseguire un lavoro
La sezione seguente fornisce le possibili soluzioni per la risoluzione dei problemi riscontrati durante il tentativo di eseguire un processo.
## `srun` interactive job fallisce con errore `srun: error: fwd_tree_thread: impossibile trovare l'indirizzo per l'host, controlla slurm.conf < >`
+ **Perché ha fallito? **
È stato eseguito il `srun` comando per inviare un lavoro e quindi è stata aumentata la dimensione di una coda utilizzando il `pcluster update-cluster` comando senza riavviare i Slurm daemon dopo il completamento dell'aggiornamento.
Slurmorganizza i Slurm demoni in una gerarchia ad albero per ottimizzare la comunicazione. Questa gerarchia viene aggiornata solo all'avvio dei demoni.
Supponiamo di `srun` utilizzarlo per avviare un lavoro e quindi eseguire il `pcluster update-cluster` comando per aumentare la dimensione della coda. I nuovi nodi di calcolo vengono lanciati come parte dell'aggiornamento. Quindi, Slurm mette in coda il lavoro su uno dei nuovi nodi di calcolo. In questo caso, entrambi i Slurm demoni e `srun` non rilevano i nuovi nodi di calcolo. `srun`restituisce un errore perché non rileva i nuovi nodi.
+ **Come risolvere? **
Riavviate Slurm i demoni su tutti i nodi di calcolo, quindi utilizzateli `srun` per inviare il lavoro. È possibile pianificare il riavvio dei Slurm daemon eseguendo il `scontrol reboot` comando che riavvia i nodi di calcolo. Per ulteriori informazioni, vedere [ scontrol reboot nella documentazione. ](https://slurm.schedmd.com/scontrol.html#OPT_reboot) Slurm È inoltre possibile riavviare manualmente i Slurm daemon sui nodi di calcolo richiedendo il riavvio dei servizi corrispondenti. `systemd`
## Il lavoro è bloccato nello stato `CF` con il comando squeue ``
Questo potrebbe essere un problema con l'accensione dei nodi dinamici. Per ulteriori informazioni, consulta [Visualizzazione di errori nelle inizializzazioni dei nodi di calcolo](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Esecuzione di lavori su larga scala e visualizzazione di `nfsd: troppe connessioni aperte, valuta la possibilità di aumentare il numero di thread in//messages var/log`
Con un file system in rete, quando vengono raggiunti i limiti di rete, aumenta anche il tempo di attesa. I/O Ciò può comportare blocchi software perché la rete viene utilizzata per scrivere dati sia per la rete che per le metriche. I/O
Con le istanze di quinta generazione, utilizziamo il driver ENA per esporre i contatori di pacchetti. Questi contatori contano i pacchetti formati da AWS quando la rete raggiunge i limiti di larghezza di banda dell'istanza. Puoi controllare questi contatori per vedere se sono maggiori di 0. Se lo sono, significa che hai superato i limiti di larghezza di banda. Puoi visualizzare questi contatori eseguendo. `ethtool -S eth0 | grep exceeded`
Il superamento dei limiti di rete è spesso il risultato del supporto di troppe connessioni NFS. Questa è una delle prime cose da verificare quando si raggiungono o si superano i limiti di rete.
Ad esempio, il seguente output mostra i pacchetti eliminati:
```
$ 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
```
Per evitare di ricevere questo messaggio, valuta la possibilità di cambiare il tipo di istanza del nodo principale con un tipo di istanza più performante. Valuta la possibilità di spostare lo storage dei dati su file system di storage condivisi che non vengono esportati come condivisione NFS, come Amazon EFS o Amazon FSx. Per ulteriori informazioni, consulta [Archiviazione condivisa](shared-storage-quotas-integration-v3.md) la sezione dedicata [ alle ](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) best practice sul AWS ParallelCluster wiki. GitHub
## Esecuzione di un job MPI
### Attivazione della modalità di debug
Per abilitare la modalità di debug di OpenMPI, vedi [ Quali controlli ha Open MPI per il debug. ](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls)
Per abilitare la modalità di debug IntelMPI, vedete Altre variabili di ambiente. [https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html)
### Visualizzazione di `MPI_ERRORS_ARE_FATAL e OPAL` ERROR nell'output del lavoro ``
Questi codici di errore provengono dal livello MPI dell'applicazione. Per informazioni su come ottenere i log di debug MPI dall'applicazione, consulta. [Attivazione della modalità di debug](#run-job-mpi-enable-v3)
Una possibile causa di questo errore è che l'applicazione è stata compilata per un'implementazione MPI specifica, come OpenMPI, e si sta tentando di eseguirla con un'implementazione MPI diversa, come IntelMPI. Assicuratevi di compilare ed eseguire l'applicazione con la stessa implementazione MPI.
### Utilizzo di `mpirun` con DNS gestito disabilitato
Per i cluster creati con [ SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[DNS](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns)/[DisableManagedDns](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns)e [ UseEc2Hostnames ](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) impostati su`true`, il nome del Slurm nodo non viene risolto dal DNS. Slurmpuò avviare i processi MPI quando `nodenames` non sono abilitati e se il job MPI viene eseguito in un contesto. Slurm Si consiglia di seguire le indicazioni contenute nella Guida per l'utente [Slurm MPI ](https://slurm.schedmd.com/mpi_guide.html) per eseguire i processi MPI con. Slurm