Jalankan alasan kegagalan - AWS HealthOmics
Panduan untuk proses yang tidak responsif

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

Jalankan alasan kegagalan

Jika proses gagal, gunakan operasi GetRunAPI 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 kepala sekolah dalam hubungan kepercayaan untuk peran tersebut.

CANNOT_START_CONTAINER_ERROR

Tidak dapat memulai tugas alur kerja:name, id: ID wadah menggunakan gambar:image name. Pastikan gambar tersebut valid dan coba lagi.

CANNOT_START_CONTAINER_SIZE_ERROR

Tidak dapat memulai tugas alur kerja:name, id: ID wadah menggunakan gambar:image name. Pastikan ukuran gambar kurang dari 25 GB 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 kepala layanan. HealthOmics

EXPORT_FAILED

Ekspor gagal. Periksa apakah bucket keluaran ada dan peran run memiliki izin tulis ke bucket.

FILE_SYSTEM_OUT_OF_SPACE

 Sistem file tidak memiliki cukup ruang. Tingkatkan ukuran sistem file dan jalankan lagi.

IMAGE_VERIFICATION_FAILURE

Tidak dapat memverifikasi gambarimage name. Untuk memperbaiki masalah, coba tarik gambar dan kemudian dorong ke repositori ECR Anda lagi.

IMPORT_FAILED

Impor gagal. Periksa apakah file input ada dan peran run dapat mengakses input.
INACTIVE_OMICS_STORAGE_RESOURCE

URI HealthOmics penyimpanan tidak dalam status AKTIF. Aktifkan set baca dan coba lagi. Untuk mempelajari selengkapnya tentang mengaktifkan set baca, lihatMengaktifkan set baca di HealthOmics.
INPUT_URI_NOT_FOUND URI yang disediakan tidak ada:uri. Periksa apakah jalur URI ada dan konfirmasikan bahwa peran dapat mengakses objek.

INSTANCE_RESERVATION_FAILED

Tidak ada kapasitas instance yang cukup untuk menyelesaikan alur kerja. Tunggu dan coba jalankan alur kerja lagi.
TIDAK VALID_ECR_IMAGE_URI

Struktur URI gambar Amazon ECR tidak valid. Berikan URI yang valid dan coba lagi.

INVALID_TASK_RESOURCE_VALUE

 GPU, CPU, atau memori yang diminta terlalu tinggi untuk kapasitas komputasi yang tersedia, atau kurang dari nilai minimum 1 untuk tugas. ID

INPUT URI_TIDAK VALID_

 Struktur URI tidak validuri. Periksa struktur URI dan coba lagi.
MODIFIED_INPUT_RESOURCE

URI yang disediakan uri telah dimodifikasi setelah proses dimulai. Coba lagi lari.

OUT_OF_MEMORY_ERROR

Tugas alur kerja ID kehabisan memori. Tingkatkan nilai memori dalam definisi alur kerja dan coba jalankan lagi.

RUN_TASK_FAILED

Jalankan gagal karena tugas gagal. Untuk men-debug kegagalan tugas, gunakan operasi GetRunTaskAPI dan aliran Amazon CloudWatch Logs.

RUN_TIMED_OUT

Jalankan batas waktu setelah beberapa number menit.
SERVICE_ERROR Ada kesalahan sementara dalam layanan. Coba jalankan alur kerja lagi.

TIDAK DISUPPORTED_INPUT_SIZE

Ukuran input total terlalu tinggi. Kurangi ukuran input dan coba lagi.

WORKFLOW_RUN_FAILED

Alur kerja berjalan gagal. Tinjau aliran CloudWatch log mesin Log: ID untuk men-debug kegagalan.

WORKFLOW_VER_VALIDATION_FAILED

HealthOmics tidak mendukung versi Nextflow yang diminta: version --. Versi terbaru yang didukung adalahversion. Ubah versi Nextflow Anda ke versi yang didukung dan coba lagi.

TIDAK DISUPPORTED_GPU_INSTANCE_TYPE

Jenis instance yang diminta tidak didukung diRegion. Coba lagi jalankan dengan jenis instans GPU yang didukung di Wilayah ini. Jenis instance yang tersedia adalahGPU instance types.

Panduan untuk proses 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. Hal ini dapat menjadi tantangan untuk memecahkan masalah dan catch, karena itu normal untuk tugas berjalan untuk waktu yang lama. 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 yang tidak responsif, dan memerlukan perubahan pada kode definisi alur kerja Anda untuk menyelesaikannya.

  • Berikan memori dan alokasi CPU yang sesuai untuk tugas Anda. Analisis CloudWatch log atau gunakan alur kerja yang Jalankan Analyzer 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 instance jika instance membutuhkan throughput yang lebih tinggi. EC2 Instans Amazon dengan kurang dari 16 v CPUs (ukuran 4xl dan lebih kecil) dapat mengalami ledakan throughput. Untuk informasi selengkapnya tentang throughput EC2 instans Amazon, lihat Bandwidth instans EC2 yang tersedia Amazon.

  • Pastikan Anda menggunakan ukuran sistem file yang benar untuk menjalankan Anda. Untuk proses 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 run maksimal yang disetel untuk menangkap kode runaway. Misalnya, jika lari membutuhkan waktu 1 jam untuk menyelesaikannya, letakkan di grup lari yang habis waktu setelah 2 atau 3 jam (atau periode waktu yang berbeda berdasarkan kasus penggunaan Anda) untuk menangkap pekerjaan run-away. Juga, terapkan buffer untuk memperhitungkan varians dalam waktu pemrosesan.

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

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

  • Periksa CloudWatch log untuk tugas yang Anda curigai mungkin 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 proses yang tidak responsif

  • Batalkan proses untuk menghindari 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 yang mungkin menyebabkan perilaku tidak responsif.

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

    • ARN dari stuck run dan ARN dari run identik yang berhasil diselesaikan.

    • 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.