翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ジョブの実行を試行する
次のセクションでは、ジョブを実行しようとして問題が発生した場合に役立つトラブルシューティングソリューションを示します。
## `srun` のインタラクティブなジョブがエラー `srun: error: fwd_tree_thread: can't find address for , check slurm.conf` で失敗する
+ **失敗した原因**
`srun` コマンドを実行してジョブを送信し、更新が完了した後、Slurm デーモンを再起動せずに `pcluster update-cluster` コマンドを使用してキューサイズを増やしました。
Slurm は、Slurm デーモンをツリー階層に整理して通信を最適化します。この階層は、デーモンが開始するときにのみ更新されます。
`srun` を使用してジョブを起動し、`pcluster update-cluster` コマンドを実行してキューサイズを増やすとします。新しいコンピューティングノードは、更新の一環として起動します。次に、Slurm は、新しいコンピューティングノードの 1 つに、ジョブをキューに入れます。この場合、Slurm デーモンと `srun` の両方は新しいコンピューティングノードを検出しません。`srun` は新しいノードを検出しないため、エラーを返します。
+ **解決方法**
すべてのコンピューティングノードで Slurm デーモンを再起動し、`srun` を使用してジョブを送信します。コンピューティングノードを再起動する `scontrol reboot` コマンドを実行することにより、Slurm デーモンの再起動をスケジュールできます。詳細については、「Slurm ドキュメント」の「[scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot)」を参照してください。また、対応する `systemd` サービスの再起動をリクエストすることにより、コンピューティングノードで Slurm デーモンを手動で再起動することもできます。
## ジョブが `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 より大きいかどうかを確認できます。その場合、帯域幅制限を超えていることになります。`ethtool -S eth0 | grep exceeded` を実行するとこれらのカウンターが表示されます。
サポートする NFS 接続が多すぎると、多くの場合、ネットワーク制限を超えます。これは、ネットワークの制限に到達したり、それを超えたりしたときに最初に確認することの 1 つです。
例えば、次の出力にドロップされたパッケージを示します。
```
$ 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
```
このメッセージの表示を回避するには、ヘッドノードのインスタンスタイプをよりパフォーマンスの高いインスタンスタイプに変更することを検討します。データストレージを、Amazon EFS や Amazon FSx などの NFS 共有としてエクスポートされていない共有ストレージファイルシステムに移行することを検討します。詳細については、[共有ストレージ](shared-storage-quotas-integration-v3.md)「」および GitHub の AWS ParallelCluster Wiki の[「ベストプラクティス](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices)」を参照してください。
## MPI ジョブを実行する
### デバッグモードを有効にする
OpenMPI デバッグモードを有効にするには、「[What controls does Open MPI have that aid in debugging](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls)」を参照してください。
IntelMPI デバッグモードを有効にするには、「[Other Environment Variables](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` に設定して作成されたクラスターの場合、Slurm ノード名は DNS によって解決されません。Slurm は、MPI ジョブが Slurm コンテキストで実行されていて、`nodenames` が有効になっていないとき、MPI プロセスをブートストラップできます。「[Slurm MPI User's Guide](https://slurm.schedmd.com/mpi_guide.html)」のガイダンスに従い、Slurm を使用して MPI ジョブを実行することをお勧めします。