As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Tentar executar um trabalho
<a name="troubleshooting-fc-v3-run-job"></a>

A seção a seguir fornece possíveis soluções caso você tenha problemas ao tentar executar um trabalho.

## O trabalho interativo do `srun` falha com erro `srun: error: fwd_tree_thread: can't find address for <host>, check slurm.conf`
<a name="run-job-srun-interactive-fail-v3"></a>
+ **Por que falhou?**

  Você executou o comando `srun` para enviar um trabalho e, em seguida, aumentou o tamanho de uma fila usando o comando `pcluster update-cluster`, sem reiniciar os daemons Slurm após a conclusão da atualização.

  O Slurm organiza os daemons Slurm em uma hierarquia de árvores para otimizar a comunicação. Essa hierarquia só é atualizada quando os daemons são iniciados.

  Suponha que você use `srun` para iniciar um trabalho e, em seguida, executar o comando `pcluster update-cluster` para aumentar o tamanho da fila. Novos nós de computação são lançados como parte da atualização. Em seguida, o Slurm enfileira seu trabalho em um dos novos nós de computação. Nesse caso, tanto os daemons Slurm quanto o `srun` não detectam os novos nós de computação. O `srun` retorna um erro porque não detecta os novos nós.
+ **Como resolver?**

  Reinicie os daemons Slurm em todos os nós de computação e use `srun` para enviar seu trabalho. Você pode programar a reinicialização dos daemons Slurm executando o comando `scontrol reboot` que reinicia os nós de computação. Para obter mais informações, consulte [scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot) na documentação do Slurm. Você também pode reiniciar manualmente os daemons Slurm nos nós de computação solicitando a reinicialização dos serviços `systemd` correspondentes.

## Trabalho está preso no estado `CF` com o comando `squeue`
<a name="run-job-cf-stuck-v3"></a>

Isso pode ser um problema com a inicialização dos nós dinâmicos. Para obter mais informações, consulte [Vendo erros nas inicializações dos nós de computação](troubleshooting-fc-v3-compute-node-initialization-v3.md).

## Executando trabalhos em grande escala e vendo `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`
<a name="run-job-network-limits-v3"></a>

Com um sistema de arquivos em rede, quando os limites da rede são atingidos, o tempo de I/O espera também aumenta. Isso pode resultar em travamentos leves porque a rede é usada para gravar dados tanto para redes quanto para I/O métricas.

Com instâncias de 5ª geração, usamos o driver ENA para expor os contadores de pacotes. Esses contadores contam os pacotes formados pelo AWS momento em que a rede atinge os limites de largura de banda da instância. Você pode verificar esses contadores para ver se eles são maiores que 0. Se estiverem, você excedeu seus limites de largura de banda. Você pode ver esses contadores executando `ethtool -S eth0 | grep exceeded`.

Exceder os limites da rede geralmente é resultado do suporte a muitas conexões NFS. Essa é uma das primeiras coisas a verificar quando você atinge ou excede os limites da rede.

Por exemplo, a saída a seguir mostra pacotes 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 receber essa mensagem, considere alterar o tipo de instância do nó principal para um tipo de instância com melhor desempenho. Considere transferir seu armazenamento de dados para sistemas de arquivos de armazenamento compartilhado que não são exportados como um compartilhamento NFS, como Amazon EFS ou Amazon. FSx Para obter mais informações, consulte [Armazenamento compartilhado](shared-storage-quotas-integration-v3.md) e as [melhores práticas](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) no AWS ParallelCluster Wiki em GitHub.

## Executando um trabalho de MPI
<a name="run-job-mpi-v3"></a>

### Habilitar o modo de depuração
<a name="run-job-mpi-enable-v3"></a>

Para ativar o modo de depuração do OpenMPI, consulte [What controls does Open MPI have that aid in debugging (Quais controles o Open MPI tem que auxiliam na depuração)](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls).

Para ativar o modo de depuração do IntelMPI, consulte [Other Environment Variables (Outras variáveis de ambiente)](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html).

### Visualizando `MPI_ERRORS_ARE_FATAL` e `OPAL ERROR` na saída do trabalho
<a name="run-job-mpi-errors-v3"></a>

Esses códigos de erro vêm da camada MPI em seu aplicativo. Para saber como obter logs de depuração do MPI do seu aplicativo, consulte [Habilitar o modo de depuração](#run-job-mpi-enable-v3).

Uma possível causa desse erro é que seu aplicativo foi compilado para uma implementação de MPI específica, como o OpenMPI, e você está tentando executá-lo com uma implementação de MPI diferente, como o IntelMPI. Verifique se você está compilando e executando seu aplicativo com a mesma implementação de MPI.

### Usando `mpirun` com o DNS gerenciado desativado
<a name="run-job-mpi-dns-disabled-v3"></a>

Para clusters criados com [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) definidos como`true`, o nome do Slurm nó não é resolvido pelo DNS. Slurmpodem inicializar processos MPI quando `nodenames` não estão habilitados e se a tarefa MPI for executada em um contexto. Slurm Recomendamos seguir as orientações do [Guia do Usuário de MPI do Slurm](https://slurm.schedmd.com/mpi_guide.html) para executar trabalhos do MPI com Slurm.