Jalankan alasan kegagalan

Jika proses gagal, gunakan operasi GetRun API untuk mengambil alasan kegagalan.

Tinjau alasan kegagalan untuk membantu Anda memecahkan masalah mengapa proses gagal. Tabel berikut mencantumkan setiap alasan kegagalan bersama dengan deskripsi kesalahan.

Alasan kegagalan	Deskripsi kesalahan
ASSUME_ROLE_FAILED	HealthOmics tidak memiliki izin untuk mengambil peran. Tentukan HealthOmics prinsipal dalam hubungan kepercayaan untuk peran tersebut.
TIDAK DAPAT_MEMULAI_CONTAINER_ERROR	Tidak dapat memulai tugas alur kerja:name, id: ID wadah menggunakan image:image name. Pastikan gambar itu valid dan coba lagi.
TIDAK DAPAT_MEMULAI_KONTAINER_SIZE_ERROR	Tidak dapat memulai tugas alur kerja:name, id: ID wadah menggunakan image:image name. Pastikan ukuran gambar kurang dari 45 GiB (95 GiB untuk instance GPU) dan coba lagi.
ECR_PERMISSION_ERROR	HealthOmics tidak memiliki izin untuk mengakses URI gambar. Konfirmasikan bahwa repositori pribadi Amazon ECR ada dan telah memberikan akses ke HealthOmics prinsipal layanan.
EKSPOR_GAGAL	Ekspor gagal. Periksa apakah bucket keluaran ada dan peran run memiliki izin menulis ke bucket.
FILE_SYSTEM_OUT_OF_SPACE	Sistem file tidak memiliki cukup ruang. Tingkatkan ukuran sistem file dan jalankan lagi.
GAGAL VERIFIKASI GAMBAR	Tidak dapat memverifikasi gambarimage name. Untuk memperbaiki masalah, coba tarik gambar dan kemudian dorong ke repositori ECR Anda lagi.
IMPOR_GAGAL	Impor gagal. Periksa apakah file input ada dan peran run dapat mengakses input.
SUMBER DAYA PENYIMPANAN_OMICS_INAKTIF_	URI HealthOmics penyimpanan tidak dalam keadaan AKTIF. Aktifkan set baca dan coba lagi. Untuk mempelajari selengkapnya tentang mengaktifkan set baca, lihatMengaktifkan set baca di HealthOmics.
MASUKAN_URI_TIDAK DITEMUKAN	URI yang disediakan tidak ada:uri. Periksa apakah jalur URI ada dan konfirmasikan bahwa peran dapat mengakses objek.
INSTANCE_RESERVATION_GAGAL	Tidak ada kapasitas instans yang cukup untuk menyelesaikan proses alur kerja. Tunggu dan coba jalankan alur kerja lagi. Untuk mempelajari selengkapnya tentang mitigasi kesalahan gagal reservasi instans, lihatMengurangi kesalahan INSTANCE_RESERVATION_FAILED.
ECR_IMAGE_URI TIDAK VALID	Struktur URI gambar Amazon ECR tidak valid. Berikan URI yang valid dan coba lagi.
NILAI_TASK_RESOURCE_VALID	GPU, CPU, atau memori yang diminta terlalu tinggi untuk kapasitas komputasi yang tersedia, atau kurang dari nilai minimum 1 untuk tugasID.
MASUKAN_URI TIDAK VALID	Struktur URI tidak validuri. Periksa struktur URI dan coba lagi.
SUMBER MASUKAN_YANG DIMODIFIKASI	URI yang disediakan uri dimodifikasi setelah proses dimulai. Coba lagi menjalankan.
OUT_OF_MEMORY_ERROR	Tugas alur ID kerja kehabisan memori. Tingkatkan nilai memori dalam definisi alur kerja dan coba jalankan lagi.
RUN_TASK_GAGAL	Jalankan gagal karena tugas gagal. Untuk men-debug kegagalan tugas, gunakan operasi GetRunTask API dan aliran Amazon CloudWatch Logs.
RUN_TIME_OUT	Jalankan batas waktu setelah beberapa number menit.
SERVICE_ERROR	Ada kesalahan sementara dalam layanan. Coba jalankan alur kerja lagi.
TUGAS_TERWAKTU_HABIS	Tugas id habis waktu setelah beberapa number detik.
UKURAN_MASUKAN_TIDAK DIDUKUNG	Ukuran input total terlalu tinggi. Kurangi ukuran input dan coba lagi.
ALUR KERJA_RUN_FAILED	Proses alur kerja gagal. Tinjau aliran CloudWatch log engine Logs: ID untuk men-debug kegagalan.
ALUR KERJA_VER_VALIDATION_GAGAL	HealthOmics tidak mendukung versi Nextflow yang diminta: version --. Versi terbaru yang didukung adalahversion. Ubah versi Nextflow Anda ke versi yang didukung dan coba lagi.
TIPE_INSTANCE_GPU TIDAK DIDUKUNG	Jenis instans yang diminta tidak didukung diRegion. Coba lagi menjalankan dengan jenis instance GPU yang didukung di Wilayah ini. Jenis instance yang tersedia adalahGPU instance types.

Mengurangi kesalahan INSTANCE_RESERVATION_FAILED

Instans GPU adalah sumber daya sesuai permintaan yang mungkin tidak selalu tersedia segera di Zona Ketersediaan atau Wilayah pilihan Anda.

HealthOmics Apa yang dilakukan secara otomatis

HealthOmics melakukan beberapa pengoptimalan atas nama Anda untuk memaksimalkan keberhasilan akuisisi GPU:

• Multi-AZ pencarian: HealthOmics memeriksa beberapa Zona Ketersediaan untuk kapasitas GPU, bukan hanya satu AZ.

• Percobaan ulang otomatis: Ketika GPU tidak segera tersedia, HealthOmics coba lagi beberapa kali untuk memperoleh kapasitas saat tersedia.

• Retensi GPU di seluruh tugas: Ketika alur kerja Anda memiliki tugas berurutan yang memerlukan GPU, per HealthOmics tahankan GPU yang sudah Anda miliki untuk tugas-tugas berikutnya daripada melepaskannya dan meminta ulang, memastikan penyelesaian alur kerja GPU multi-langkah berhasil.

Praktik terbaik tambahan berikut dapat meningkatkan tingkat keberhasilan Anda saat menjalankan alur GPU-accelerated kerja pada: HealthOmics

1. Gunakan bundel akselerator untuk memaksimalkan fleksibilitas

   Alih-alih meminta jenis instance GPU tertentu, gunakan bundel akselerator yang memungkinkan HealthOmics untuk memilih dari beberapa generasi GPU yang kompatibel (misalnya, g4dn, g5, g6). Semakin banyak jenis GPU yang dapat diterima alur kerja Anda, semakin tinggi kemungkinan menemukan kapasitas yang tersedia.

   Untuk mempelajari selengkapnya, lihat Akselerator tugas dalam definisi al HealthOmics ur kerja. Contoh:

   • nvidia-t4-a10g-l4mengambil dari keluarga instans G4, G5, dan G6

   • nvidia-l4-a10gmengambil dari keluarga instans G5 dan G6

2. Pertimbangkan untuk menjalankan alur kerja Anda di Wil AWS ayah lain

   Ketersediaan GPU bervariasi di seluruh AWS Wilayah. Jika persyaratan tempat tinggal data memungkinkan, pertimbangkan untuk menjalankan GPU-intensive alur kerja di Wilayah lain di mana kapasitas mungkin lebih tersedia. Untuk mempelajari lebih lanjut tentang Wilayah yang didukung, lihat Kuota layanan dan titik akhir untuk AWS HealthOmics.

3. Konfigurasikan fallback sumber daya (Hanya alur kerja WDL)

   Untuk alur kerja WDL, direktif omicsResourceFallbackOrder memungkinkan Anda menentukan daftar profil sumber daya yang diurutkan (GPU atau CPU) per tugas. Jika jenis akselerator pilihan Anda tidak tersedia, HealthOmics secara otomatis mencoba jenis akselerator atau CPU berikutnya alih-alih gagal. Anda juga dapat menentukan berapa lama HealthOmics harus mencari GPU. Kasus penggunaan meliputi:

   • Fallback GPU ke GPU — coba akselerator pilihan Anda terlebih dahulu, lalu kembali ke alternatif (misalnya, coba nvidia-l40s dulu, kemudiannvidia-l4).

   • Fallback GPU ke CPU — tambahkan CPU-only profil akhir sehingga tugas selesai bahkan ketika tidak ada kapasitas GPU yang tersedia.

   catatan

   omicsResourceFallbackOrderDirektif saat ini didukung untuk alur kerja WDL saja. Dukungan Nextflow direncanakan.

   Untuk mempelajari selengkapnya, lihat Konfigurasi sumber daya lanjutan.

Panduan untuk lari yang tidak responsif

Saat mengembangkan alur kerja baru, proses atau tugas tertentu bisa menjadi “macet” atau “hang” jika ada masalah dengan kode Anda, dan tugas gagal keluar dari proses dengan benar. Ini bisa menjadi tantangan untuk dipecahkan dan ditangkap, karena tugas berjalan untuk waktu yang lama adalah hal yang normal. Untuk mencegah dan mengidentifikasi proses yang tidak responsif, ikuti praktik terbaik yang disarankan di bagian berikut.

Praktik terbaik untuk mencegah proses yang tidak responsif

• Pastikan Anda menutup semua file yang dibuka dalam kode tugas Anda. Membuka terlalu banyak file kadang-kadang dapat menyebabkan masalah threading dalam mesin alur kerja.

• Proses latar belakang yang dibuat oleh tugas alur kerja harus keluar saat tugas keluar. Namun, jika proses latar belakang tidak keluar dengan bersih, Anda harus secara eksplisit mematikan proses itu dalam kode tugas Anda.

• Pastikan proses Anda tidak berputar tanpa keluar. Hal ini dapat menyebabkan proses tidak responsif, dan memerlukan perubahan pada kode definisi alur kerja Anda untuk diselesaikan.

• Berikan memori dan alokasi CPU yang sesuai untuk tugas Anda. Analisis CloudWatch log atau gunakan alur kerja Jalankan Analyzer yang berhasil diselesaikan untuk memverifikasi bahwa Anda memiliki alokasi komputasi yang optimal. Gunakan headroom parameter Run Analyzer untuk menyertakan headroom tambahan, memastikan proses memiliki sumber daya yang cukup untuk diselesaikan. Sertakan setidaknya 5% headroom dalam memori dan CPU yang dialokasikan, untuk memperhitungkan proses sistem operasi latar belakang.

  • Selain itu, tingkatkan ukuran bandwidth instans jika instance memerlukan throughput yang lebih tinggi. Instans Amazon EC2 dengan kurang dari 16 vCPU (ukuran 4xl dan lebih kecil) dapat mengalami ledakan throughput. Untuk informasi selengkapnya tentang throughput instans Amazon EC2, lihat Bandwidth instans Amazon EC2 yang tersedia.

• Pastikan Anda menggunakan ukuran sistem file yang benar untuk menjalankan Anda. Untuk proses yang tidak responsif yang menggunakan penyimpanan run statis, pertimbangkan untuk meningkatkan alokasi penyimpanan run statis untuk mengaktifkan throughput IO dan kapasitas penyimpanan yang lebih tinggi pada sistem file. Analisis manifes run untuk melihat penyimpanan sistem file maksimum, gunakan Run Analyzer untuk menentukan apakah alokasi sistem file perlu ditingkatkan.

Praktik terbaik untuk menangkap proses yang tidak responsif

• Saat mengembangkan alur kerja baru, gunakan grup run dengan batas waktu berjalan maksimal yang ditetapkan untuk menangkap kode pelarian. Misalnya, jika proses harus memakan waktu 1 jam untuk diselesaikan, letakkan di grup run yang habis waktu setelah 2 atau 3 jam (atau periode waktu yang berbeda berdasarkan kasus penggunaan Anda) untuk menangkap pekerjaan yang tidak berhasil. Juga, terapkan buffer untuk memperhitungkan varians dalam waktu pemrosesan.

• Siapkan serangkaian grup run dengan batas runtime maksimum yang berbeda. Misalnya, Anda dapat menetapkan run pendek ke grup run yang mengakhiri proses setelah beberapa jam, dan grup lari panjang yang menghentikan proses setelah beberapa hari, berdasarkan durasi alur kerja yang diharapkan.

• HealthOmics memiliki batas layanan durasi berjalan maksimum default 604.800 Detik, atau 7 hari, yang dapat disesuaikan melalui permintaan di alat kuota. Hanya minta kenaikan batas layanan dari kuota ini jika Anda telah menjalankan yang durasi mendekati seminggu. Jika Anda memiliki campuran lari pendek dan panjang dan tidak menggunakan grup run, pertimbangkan untuk meletakkan run yang berjalan lama di akun terpisah dengan batas layanan durasi lari maksimum yang lebih tinggi.

• Periksa CloudWatch log untuk tugas-tugas yang Anda duga tidak responsif. Jika tugas biasanya mengeluarkan pernyataan log reguler dan belum melakukannya untuk waktu yang lama, tugas tersebut kemungkinan macet atau beku.

Apa yang harus dilakukan jika Anda mengalami run yang tidak responsif

• Batalkan lari untuk menghindari menimbulkan biaya tambahan.

• Periksa log tugas untuk memeriksa apakah ada proses yang gagal keluar dengan benar.

• Periksa log mesin untuk mengidentifikasi perilaku mesin yang tidak normal.

• Bandingkan log tugas dan mesin dari proses yang tidak responsif dengan proses yang identik dan berhasil diselesaikan. Ini dapat membantu mengidentifikasi perbedaan apa pun yang mungkin menyebabkan perilaku tidak responsif.

• Jika Anda tidak dapat menentukan akar penyebabnya, angkat kasus dukungan dan sertakan yang berikut:

  • ARN dari run macet dan ARN dari run identik yang diselesaikan dengan sukses.

  • Log mesin (tersedia setelah proses dibatalkan atau gagal)

  • Log tugas untuk tugas yang tidak responsif. Kami tidak memerlukan log tugas untuk semua tugas dalam alur kerja untuk memecahkan masalah.