기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 작업을 실행하려는 경우
다음 섹션에서는 작업 실행 중에 문제가 발생할 경우 가능한 문제 해결 솔루션을 제공합니다.
## `srun` 대화형 작업이 `srun: error: fwd_tree_thread: can't find address for , check slurm.conf` 오류가 발생하여 실패합니다.
+ **왜 실패했나요?**
`srun` 명령을 실행하여 작업을 제출한 다음 업데이트가 완료된 후 Slurm 대몬(daemon)을 다시 시작하지 않고 `pcluster update-cluster` 명령을 사용하여 대기열 크기를 늘렸습니다.
Slurm은 통신을 최적화하기 위해 Slurm 대몬(daemon)을 트리 계층으로 구성합니다. 이 계층 구조는 대몬(daemon)이 시작될 때만 업데이트됩니다.
`srun`를 사용하여 작업을 시작한 다음 `pcluster update-cluster` 명령을 실행하여 대기열 크기를 늘린다고 가정해 보겠습니다. 업데이트의 일부로 새 컴퓨팅 노드가 시작됩니다. 그런 다음 새 컴퓨팅 노드 중 하나에 작업을 Slurm 대기열에 추가합니다. 이 경우 Slurm 대몬(daemon)과 `srun`는 모두 새 컴퓨팅 노드를 감지하지 못합니다. `srun`은 새 노드를 감지하지 못하므로 오류가 반환됩니다.
+ **해결 방법은?**
모든 컴퓨팅 노드에서 Slurm 대몬(daemon)을 재시작한 다음 `srun`를 사용하여 작업을 제출하세요. 컴퓨팅 노드를 재시작하는 `scontrol reboot` 명령을 실행하여 Slurm 대몬(daemon) 재시작을 예약할 수 있습니다. 자세한 내용은 Slurm 설명서의 [scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot)를 참조하세요. 대응하는 `systemd` 서비스의 재시작을 요청하여 컴퓨팅 노드에서 Slurm 대몬(daemon)을 수동으로 재시작할 수도 있습니다.
## 작업이 `squeue` 명령을 실행한 `CF` 상태에서 멈췄습니다.
동적 노드의 전원을 켤 때 발생하는 문제일 수 있습니다. 자세한 내용은 [컴퓨팅 노드 초기화 오류가 표시되는 경우](troubleshooting-fc-v3-compute-node-initialization-v3.md) 항목을 참조하세요.
## 대규모 작업을 실행한 후 `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`가 표시된 경우
네트워크로 연결된 파일 시스템에서 네트워크 제한에 도달하면 I/O 대기 시간도 늘어납니다. 네트워크가 네트워킹 및 I/O 지표 모두에 대한 데이터를 쓰는 데 사용되므로 소프트 록업이 발생할 수 있습니다.
5세대 인스턴스에서는 패킷 카운터를 노출하기 위해 ENA 드라이버가 사용됩니다. 이러한 카운터는 네트워크가 인스턴스 대역폭 제한에 도달할 AWS 때에 의해 형성된 패킷 수를 계산합니다. 이러한 카운터가 0보다 큰지 확인할 수 있습니다. 0보다 크다면 대역폭 한도를 초과한 것입니다. `ethtool -S eth0 | grep exceeded`를 실행하여 이러한 카운터를 볼 수 있습니다.
네트워크 한도를 초과하는 것은 NFS 연결을 너무 많이 지원한 결과인 경우가 많습니다. 이는 네트워크 한도에 도달하거나 초과할 때 가장 먼저 확인해야 할 사항 중 하나입니다.
예를 들어 다음 출력은 누락된 패키지를 표시합니다.
```
$ 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
```
이 메시지가 표시되지 않도록 헤드 노드 인스턴스 유형을 성능이 더 좋은 인스턴스 유형으로 변경하는 것이 좋습니다. 데이터 스토리지를 NFS 공유로 내보내지 않는 공유 스토리지 파일 시스템(예: Amazon EFS 또는 Amazon FSx)으로 옮기는 것을 고려해 보세요. 자세한 내용은 [공유 스토리지](shared-storage-quotas-integration-v3.md) 및 GitHub의 AWS ParallelCluster Wiki [모범 사례를](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) 참조하세요.
## MPI 작업 실행
### 디버그 모드 활성화
OpenMPI 디버그 모드를 활성화하려면 [디버깅에 도움이 되는 Open MPI의 제어 기능](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls)을 참조하세요.
IntelMPI 디버그 모드를 활성화하려면 [기타 환경 변수](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html)를 참조하세요.
### 작업 출력에서 `MPI_ERRORS_ARE_FATAL` 및 `OPAL ERROR`이 표시되는 경우
이러한 오류 코드는 애플리케이션의 MPI 계층에서 가져온 것입니다. 애플리케이션에서 MPI 디버그 로그를 가져오는 방법은 [디버그 모드 활성화](#run-job-mpi-enable-v3) 항목을 참조하세요.
이 오류가 발생하는 원인은 응용 프로그램이 OpenMPI와 같은 특정 MPI 구현용으로 컴파일되었고 IntelMPI와 같은 다른 MPI 구현을 사용하여 응용 프로그램을 실행하려고 하기 때문일 수 있습니다. 동일한 MPI 구현으로 애플리케이션을 컴파일하고 실행하고 있는지 확인하세요.
### 관리형 DNS를 비활성화한 상태에서 `mpirun` 사용
[SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Dns](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns)/[DisableManagedDNS](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns) 및 [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames)을 `true`로 설정하여 생성한 클러스터의 경우 DNS에서 Slurm 노드 이름을 확인하지 않습니다. Slurm은 MPI 프로세스가 `nodenames` 활성화되지 않은 경우 및 Slurm 컨텍스트에서 MPI 작업이 실행되는 경우 MPI 프로세스를 부트스트랩할 수 있습니다. [Slurm MPI 사용 설명서](https://slurm.schedmd.com/mpi_guide.html)의 지침에 따라 Slurm으로 MPI 작업을 실행하는 것이 좋습니다.