Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Mencoba menjalankan pekerjaan
<a name="troubleshooting-fc-v3-run-job"></a>

Bagian berikut menyediakan solusi pemecahan masalah yang mungkin jika Anda mengalami masalah saat mencoba menjalankan pekerjaan.

## `srun`pekerjaan interaktif gagal dengan kesalahan `srun: error: fwd_tree_thread: can't find address for <host>, check slurm.conf`
<a name="run-job-srun-interactive-fail-v3"></a>
+ **Mengapa gagal?**

  Anda menjalankan `srun` perintah untuk mengirimkan pekerjaan, dan kemudian Anda meningkatkan ukuran antrian dengan menggunakan `pcluster update-cluster` perintah tanpa memulai ulang Slurm daemon setelah pembaruan selesai.

  Slurmmengatur Slurm daemon dalam hierarki pohon untuk mengoptimalkan komunikasi. Hirarki ini hanya diperbarui saat daemon dimulai.

  Misalkan Anda menggunakan `srun` untuk meluncurkan pekerjaan dan kemudian menjalankan `pcluster update-cluster` perintah untuk meningkatkan ukuran antrian. Node komputasi baru diluncurkan sebagai bagian dari pembaruan. Kemudian, Slurm antrian pekerjaan Anda ke salah satu node komputasi baru. Dalam hal ini, baik Slurm daemon dan `srun` tidak mendeteksi node komputasi baru. `srun`mengembalikan kesalahan karena tidak mendeteksi node baru.
+ **Bagaimana cara mengatasinya?**

  Mulai ulang Slurm daemon pada semua node komputasi, dan kemudian gunakan `srun` untuk mengirimkan pekerjaan Anda. Anda dapat menjadwalkan Slurm daemon restart dengan menjalankan `scontrol reboot` perintah yang memulai ulang node komputasi. Untuk informasi selengkapnya, lihat [scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot) di Slurm dokumentasi. Anda juga dapat me-restart Slurm daemon secara manual pada node komputasi dengan meminta restart layanan terkait. `systemd`

## Job terjebak dalam `CF` keadaan dengan `squeue` perintah
<a name="run-job-cf-stuck-v3"></a>

Ini mungkin menjadi masalah dengan node dinamis yang menyala. Untuk informasi selengkapnya, lihat [Melihat kesalahan dalam inisialisasi node komputasi](troubleshooting-fc-v3-compute-node-initialization-v3.md).

## Menjalankan pekerjaan skala besar dan melihat `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`
<a name="run-job-network-limits-v3"></a>

Dengan sistem file jaringan, ketika batas jaringan tercapai, waktu I/O tunggu juga meningkat. Hal ini dapat mengakibatkan soft lockup karena jaringan digunakan untuk menulis data untuk jaringan dan I/O metrik.

Dengan instance generasi ke-5, kami menggunakan driver ENA untuk mengekspos penghitung paket. Penghitung ini menghitung paket yang dibentuk oleh AWS ketika jaringan mencapai batas bandwidth instance. Anda dapat memeriksa penghitung ini untuk melihat apakah mereka lebih besar dari 0. Jika ya, maka Anda telah melampaui batas bandwidth Anda. Anda dapat melihat penghitung ini dengan menjalankan`ethtool -S eth0 | grep exceeded`.

Melebihi batas jaringan seringkali merupakan hasil dari mendukung terlalu banyak koneksi NFS. Ini adalah salah satu hal pertama yang harus diperiksa ketika Anda mencapai atau melampaui batas jaringan.

Misalnya, output berikut menunjukkan paket yang dijatuhkan:

```
$ 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
```

Untuk menghindari pesan ini, pertimbangkan untuk mengubah tipe instance node head ke tipe instance yang lebih berkinerja. Pertimbangkan untuk memindahkan penyimpanan data Anda ke sistem file penyimpanan bersama yang tidak diekspor sebagai berbagi NFS, seperti Amazon EFS atau Amazon. FSx Untuk informasi selengkapnya, lihat [Penyimpanan bersama](shared-storage-quotas-integration-v3.md) dan [Praktik Terbaik](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) di AWS ParallelCluster Wiki di GitHub.

## Menjalankan pekerjaan MPI
<a name="run-job-mpi-v3"></a>

### Mengaktifkan mode debug
<a name="run-job-mpi-enable-v3"></a>

Untuk mengaktifkan mode debug OpenMpi, [lihat Kontrol apa yang dimiliki Open MPI](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls) yang membantu dalam debugging.

Untuk mengaktifkan mode debug IntelMpi, lihat Variabel Lingkungan [Lainnya](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html).

### Melihat `MPI_ERRORS_ARE_FATAL` dan `OPAL ERROR` dalam output pekerjaan
<a name="run-job-mpi-errors-v3"></a>

Kode kesalahan ini berasal dari lapisan MPI dalam aplikasi Anda. Untuk mempelajari cara mendapatkan log debug MPI dari aplikasi Anda, lihat. [Mengaktifkan mode debug](#run-job-mpi-enable-v3)

Kemungkinan penyebab kesalahan ini adalah aplikasi Anda telah dikompilasi untuk implementasi MPI tertentu, seperti OpenMPI, dan Anda mencoba menjalankannya dengan implementasi MPI yang berbeda, seperti IntelMPI. Pastikan Anda berdua mengkompilasi dan menjalankan aplikasi Anda dengan implementasi MPI yang sama.

### Menggunakan `mpirun` dengan DNS terkelola dinonaktifkan
<a name="run-job-mpi-dns-disabled-v3"></a>

Untuk cluster yang dibuat [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)[dengan/Dns](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns)/[DisableManagedDns](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns)dan [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) disetel ke`true`, nama Slurm node tidak diselesaikan oleh DNS. Slurmdapat mem-bootstrap proses MPI saat `nodenames` tidak diaktifkan dan jika pekerjaan MPI dijalankan dalam suatu Slurm konteks. Kami merekomendasikan mengikuti panduan dalam [Panduan Pengguna Slurm MPI](https://slurm.schedmd.com/mpi_guide.html) untuk menjalankan pekerjaan MPI dengan. Slurm