Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Intentando ejecutar un trabajo
En la siguiente sección se proporcionan posibles soluciones a problemas que puedan surgir al intentar ejecutar un trabajo.
## `srun`el trabajo interactivo falla con un error `srun: error: fwd_tree_thread: can't find address for , check slurm.conf`
+ **¿Por qué falló?**
Ejecutaste el `srun` comando para enviar un trabajo y, a continuación, aumentaste el tamaño de la cola utilizando el `pcluster update-cluster` comando sin reiniciar los Slurm daemons una vez finalizada la actualización.
Slurm organiza los daemons de Slurm en una jerarquía de árbol para optimizar la comunicación. Esta jerarquía solo se actualiza cuando se inician los daemons.
Supongamos que se inicia un trabajo y, `srun` a continuación, se ejecuta el `pcluster update-cluster` comando para aumentar el tamaño de la cola. Como parte de la actualización, se lanzan nuevos nodos de cómputo. A continuación, Slurm coloca el trabajo en cola en uno de los nuevos nodos de cómputo. En este caso, tanto los daemons de Slurm como `srun` no detectan los nuevos nodos de computación. `srun` devuelve un error porque no detecta los nuevos nodos.
+ **¿Cómo resolverlo?**
Reinicia los daemons de Slurm en todos los nodos de procesamiento y use `srun` para enviar su trabajo. Para programar el reinicio de los Slurm daemons, ejecute el `scontrol reboot` comando que reinicia los nodos de procesamiento. Para obtener más información, consulte [Paquetes de conformidad](https://slurm.schedmd.com/scontrol.html#OPT_reboot) en la documentación de Slurm. También puede reiniciar manualmente los daemons de Slurm de los nodos de computación solicitando el reinicio de los servicios de `systemd` correspondientes.
## Job está atascado en el `CF` estado con `squeue` el comando
Esto podría deberse a que los nodos dinámicos se están encendiendo. Para obtener más información, consulte [Visualización de errores en las inicializaciones de los nodos de computación](troubleshooting-fc-v3-compute-node-initialization-v3.md).
## Ejecución de trabajos a gran escala y visualización de `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`
Con un sistema de archivos en red, cuando se alcanzan los límites de la red, el tiempo de I/O espera también aumenta. Esto puede provocar bloqueos temporales, ya que la red se utiliza para escribir datos tanto para la red como para las métricas. I/O
En el caso de las instancias de quinta generación, utilizamos el controlador ENA para exponer los contadores de paquetes. Estos contadores cuentan los paquetes a los que se da forma AWS cuando la red alcanza los límites de ancho de banda de la instancia. Puede consultar estos contadores para ver si son mayores que 0. Si lo son, significa que ha superado los límites de ancho de banda. Puede ver estos contadores corriendo`ethtool -S eth0 | grep exceeded`.
Superar los límites de la red suele deberse a que se admiten demasiadas conexiones NFS. Esta es una de las primeras cosas que hay que comprobar cuando se alcanzan o se superan los límites de la red.
Por ejemplo, el siguiente resultado muestra los paquetes descartados:
```
$ 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
```
Para evitar recibir este mensaje, considere la posibilidad de cambiar el tipo de instancia del nodo principal por un tipo de instancia con más rendimiento. Considere la posibilidad de trasladar su almacenamiento de datos a sistemas de archivos de almacenamiento compartido que no se exporten como un recurso compartido de NFS, como Amazon EFS o Amazon FSx. Para obtener más información, consulte [Almacenamiento compartido](shared-storage-quotas-integration-v3.md) las [prácticas recomendadas](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) en la AWS ParallelCluster wiki sobre GitHub.
## Ejecución de trabajos de MPI
### Cómo habilitar el modo de depuración
Para habilitar el modo de depuración de OpenMPI, [consulte ¿Qué controles tiene Open MPI](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls) que ayudan a depurar?
[Para habilitar el modo de depuración de IntelMPI, consulte Otras variables de entorno.](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html)
### Visualización de `MPI_ERRORS_ARE_FATAL` y `OPAL ERROR` en el resultado del trabajo
Estos códigos de error provienen de la capa MPI de su aplicación. Para obtener información sobre cómo obtener los registros de depuración de MPI de su aplicación, consulte. [Cómo habilitar el modo de depuración](#run-job-mpi-enable-v3)
Una posible causa de este error es que la aplicación se ha compilado para una implementación de MPI específica, como OpenMPI, y está intentando ejecutarla con una implementación de MPI diferente, como IntelMPI. Asegúrese de compilar y ejecutar la aplicación con la misma implementación de MPI.
### Se utiliza `mpirun` con el DNS administrado desactivado
En el caso de los clústeres creados con [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/Dns/[DisableManagedDns](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns)y [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) configurados en`true`, el [DNS](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns) no resuelve el nombre del Slurm nodo. Slurmpuede iniciar procesos de MPI cuando `nodenames` no están habilitados y si el trabajo de MPI se ejecuta en un contexto. Slurm Recomendamos seguir las instrucciones de la Guía del [usuario de Slurm MPI para ejecutar trabajos de](https://slurm.schedmd.com/mpi_guide.html) MPI con él. Slurm