View a markdown version of this page

Motivi di errore dell'esecuzione - AWS HealthOmics

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Motivi di errore dell'esecuzione

Se una corsa fallisce, usa il GetRun Operazione API per recuperare il motivo dell'errore.

Per l'ordine in cui leggere il record di esecuzione, i record delle attività non riuscite e i log, vedi Debug di un HealthOmics esecuzione del flusso di lavoro.

Esamina il motivo dell'errore per aiutarti a risolvere il motivo per cui l'esecuzione non è riuscita. La tabella seguente elenca ogni motivo dell'errore insieme a una descrizione dell'errore.

Failure reason (Motivo errore) Descrizione dell'errore.

ALL_PROFILES_INSTANCE_RESERVATION_FAILED

La capacità di istanza non è sufficiente per nessuno degli acceleratori specificati in omicsResourceFallbackOrder direttiva. Valuta la possibilità di aumentare il tempo di attesa delle risorse o specifica acceleratori alternativi o un'opzione CPU nell'ordine alternativo. Per saperne di più sul fallback delle risorse, vedi Configurazione avanzata delle risorse.

ASSUME_ROLE_FAILED

HealthOmics non è autorizzato ad assumere il ruolo. Specifica il HealthOmics principale nella relazione di fiducia per il ruolo.

CANNOT_START_CONTAINER_ERROR

Impossibile avviare l'attività del flusso di lavoro: name, id: ID contenitore che utilizza l'immagine: image name. Assicurati che l'immagine sia valida e riprova.

CANNOT_START_CONTAINER_SIZE_ERROR

Impossibile avviare l'attività del flusso di lavoro: name, id: ID contenitore che utilizza l'immagine: image name. Assicurati che la dimensione dell'immagine sia inferiore a 45 GiB (95 GiB per un'istanza GPU) e riprova.

ECR_IMAGE_NOT_FOUND

Immagine non trovata nell'URI: uri. Assicurati che il tag o il digest dell'immagine esista nel repository Amazon ECR e riprova.

ECR_PERMISSION_ERROR

HealthOmics non dispone dell'autorizzazione per accedere all'URI dell'immagine.

Verifica che il repository privato Amazon ECR esista e abbia concesso l'accesso al HealthOmics responsabile del servizio.

ECR_REPOSITORY_NOT_FOUND

Repository Amazon ECR non trovato per l'URI dell'immagine: uri. Assicurati che il repository esista e che l'URI sia corretto, quindi riprova.

EXPORT_FAILED

L'esportazione non è riuscita. Verifica che il bucket di output esista e che il ruolo di esecuzione disponga dell'autorizzazione di scrittura per il bucket.

FILE_SYSTEM_OUT_OF_SPACE

Il file system non dispone di spazio sufficiente. Aumenta le dimensioni del file system ed esegui nuovamente.

IMAGE_VERIFICATION_FAILURE

Impossibile verificare l'immagine image name. Per risolvere il problema, prova a estrarre l'immagine e poi inviala nuovamente al tuo repository ECR.

IMPORT_FAILED

L'importazione non è riuscita. Verifica che il file di input esista e che il ruolo di esecuzione possa accedere all'input.

INACTIVE_OMICS_STORAGE_RESOURCE

Il HealthOmics l'URI di archiviazione non è in stato ATTIVO. Attiva il set di lettura e riprova. Per saperne di più sull'attivazione dei set di lettura, vedi L'attivazione dei set di lettura HealthOmics.

INPUT_URI_NOT_FOUND L'URI fornito non esiste: uri. Verifica che il percorso URI esista e conferma che il ruolo possa accedere all'oggetto.

INSTANCE_RESERVATION_FAILED

La capacità dell'istanza non è sufficiente per completare l'esecuzione del flusso di lavoro. Attendi e riprova a eseguire il flusso di lavoro. Per saperne di più sulle mitigazioni degli errori di prenotazione delle istanze non riuscite, consulta Riduzione degli errori INSTANCE_RESERVATION_FAILED.

IMAGE_ECR_URI NON VALIDO

La struttura URI dell'immagine Amazon ECR non è valida. Fornisci un URI valido e riprova.

INVALID_TASK_RESOURCE_VALUE

La GPU, la CPU o la memoria richieste sono troppo elevate per la capacità di calcolo disponibile o sono inferiori al valore minimo di 1 per l'attività ID.

INVALID_URI_INPUT

La struttura URI non è valida uri. Controlla la struttura dell'URI e riprova.
MODIFIED_INPUT_RESOURCE

L'URI fornito uri è stato modificato dopo l'inizio della corsa. Riprova a correre.

OUT_OF_MEMORY_ERROR

L'attività del flusso di lavoro ID memoria esaurita. Aumentate il valore della memoria nella definizione del flusso di lavoro e riprovate a eseguire.

RUN_TASK_FAILED

L'esecuzione non è riuscita perché l'operazione non è riuscita. Per eseguire il debug dell'operazione non riuscita, utilizzare GetRunTask Funzionamento dell'API e Amazon CloudWatch Stream di log.

RUN_TIMED_OUT

Esegui il timeout dopo number minuti.

SERVICE_ERROR Si è verificato un errore temporaneo nel servizio. Prova a eseguire nuovamente il flusso di lavoro.
TASK_TIMED_OUT Attività id scaduto dopo number secondi.

UNSUPPORTED_INPUT_SIZE

La dimensione totale dell'input è troppo alta. Riduci la dimensione dell'input e riprova.

WORKFLOW_RUN_FAILED

Esecuzione del workflow non riuscita. Rivedi il CloudWatch Registra il flusso di log del motore: ID per eseguire il debug dell'errore.

WORKFLOW_VER_VALIDATION_FAILED

HealthOmics non supporta la versione Nextflow richiesta: version --. L'ultima versione supportata è version. Modifica la tua versione di Nextflow con una versione supportata e riprova.

UNSUPPORTED_GPU_INSTANCE_TYPE

Il tipo di istanza richiesto non è supportato in Region. Riprova a eseguire l'esecuzione con un tipo di istanza GPU supportato in questa regione. I tipi di istanza disponibili sono GPU instance types.

Riduzione degli errori INSTANCE_RESERVATION_FAILED

Le istanze GPU sono risorse su richiesta che potrebbero non essere sempre immediatamente disponibili nella zona o regione di disponibilità preferita.

Cosa HealthOmics fa automaticamente

HealthOmics esegue diverse ottimizzazioni per tuo conto per massimizzare il successo dell'acquisizione della GPU:

  • Multi-AZ ricerca: HealthOmics verifica più zone di disponibilità per la capacità della GPU, non solo una singola AZ.

  • Riprovi automatici: Quando una GPU non è immediatamente disponibile, HealthOmics tenta più volte di acquisire la capacità non appena diventa disponibile.

  • Conservazione della GPU tra le attività: quando il flusso di lavoro prevede attività sequenziali che richiedono una GPU, HealthOmics mantiene la GPU di cui disponi già per le attività successive anziché rilasciarla e richiederla nuovamente, garantendo il corretto completamento dei flussi di lavoro GPU in più fasi.

Le seguenti best practice aggiuntive possono migliorare ulteriormente la percentuale di successo durante l'esecuzione GPU-accelerated flussi di lavoro su HealthOmics:

  1. Usa i pacchetti di acceleratori per massimizzare la flessibilità

    Invece di richiedere un tipo di istanza GPU specifico, utilizza pacchetti di acceleratori che consentano HealthOmics per selezionare tra più generazioni di GPU compatibili (ad esempio, g4dn, g5, g6). Maggiore è il numero di tipi di GPU accettati dal flusso di lavoro, maggiore è la probabilità di trovare capacità disponibile.

    Per ulteriori informazioni, consulta Acceleratori di attività in un HealthOmics definizione del flusso di lavoro. Ad esempio:

    • nvidia-t4-a10g-l4 attinge da famiglie di istanze G4, G5 e G6

    • nvidia-l4-a10g attinge da famiglie di istanze G5 e G6

  2. Valuta la possibilità di eseguire il flusso di lavoro in un altro AWS Regione

    La disponibilità della GPU varia a seconda AWS Regioni. Se i requisiti di residenza dei dati lo consentono, valuta la possibilità di eseguire GPU-intensive flussi di lavoro in una regione diversa in cui la capacità potrebbe essere più facilmente disponibile. Per saperne di più sulle regioni supportate, consulta Quote di servizio ed endpoint per AWS HealthOmics.

  3. Configurare il fallback delle risorse

    Per i flussi di lavoro WDL e Nextflow, puoi usare omicsResourceFallbackOrder direttiva per definire un elenco ordinato di profili di risorse (GPU o CPU) per attività. Se il tipo di acceleratore preferito non è disponibile, HealthOmics prova automaticamente il tipo di acceleratore o la CPU successivi invece di fallire. Puoi anche specificare per quanto tempo HealthOmics dovrebbe cercare una GPU. I casi d'uso includono:

    • Soluzione da GPU a GPU — prova prima il tuo acceleratore preferito, poi torna a un'alternativa (ad esempio, prova nvidia-l40s prima, poi nvidia-l4).

    • Ripiego da GPU a CPU — aggiungi una finale CPU-only profilo in modo che l'attività venga completata anche quando non è disponibile alcuna capacità GPU.

    Se nessuno dei profili nell'ordine alternativo è in grado di funzionare entro il tempo di attesa, l'esecuzione ha esito negativo ALL_PROFILES_INSTANCE_RESERVATION_FAILED. Per i flussi di lavoro WDL, HealthOmics non riprova l'operazione per questo errore. Per i flussi di lavoro Nextflow, errorStrategy e maxRetries determina se l'operazione viene ritentata e un nuovo tentativo ricomincia dal primo profilo. Valuta la possibilità di aumentare il tempo di attesa delle risorse o specifica acceleratori alternativi o un'opzione CPU nell'ordine alternativo.

    Per ulteriori informazioni, consulta Configurazione avanzata delle risorse.

Linee guida per le esecuzioni che non rispondono

Quando si sviluppano nuovi flussi di lavoro, le esecuzioni o le attività specifiche potrebbero «bloccarsi» o «bloccarsi» in caso di problemi con il codice e le attività non riescono a uscire correttamente dai processi. Questo può essere difficile da risolvere e individuare, poiché è normale che le attività vengano eseguite per periodi prolungati. Per prevenire e identificare le esecuzioni che non rispondono, segui le best practice suggerite nelle sezioni seguenti.

Procedure consigliate per prevenire le esecuzioni che non rispondono

  • Assicurati di chiudere tutti i file aperti nel codice dell'attività. L'apertura di troppi file può occasionalmente causare problemi di threading nei motori del flusso di lavoro.

  • I processi in background creati da un'attività del flusso di lavoro dovrebbero terminare quando l'attività viene chiusa. Tuttavia, se un processo in background non viene chiuso correttamente, è necessario chiuderlo esplicitamente nel codice dell'attività.

  • Assicurati che i processi non si ripetano senza uscire. Ciò può causare un'esecuzione senza risposta e richiede una modifica al codice di definizione del flusso di lavoro per risolverlo.

  • Fornisci un'allocazione appropriata di memoria e CPU per le tue attività. Analizza il CloudWatch registri o usa il Esegui Analyzer sulle esecuzioni del flusso di lavoro completate con successo per verificare di disporre di un'allocazione di elaborazione ottimale. Usa Run Analyzer headroom parametro per includere ulteriore margine di manovra, garantendo che i processi dispongano di risorse sufficienti per il completamento. Includi almeno il 5% di spazio libero nella memoria allocata e nella CPU, per tenere conto dei processi del sistema operativo in background.

    • Inoltre, aumenta la dimensione della larghezza di banda dell'istanza se l'istanza richiede un throughput più elevato. Le istanze Amazon EC2 con meno di 16 vCPU (dimensioni 4xl e inferiori) possono subire un aumento del throughput. Per ulteriori informazioni sul throughput delle istanze Amazon EC2, consulta Larghezza di banda dell'istanza disponibile di Amazon EC2.

  • Assicurati di utilizzare la dimensione del file system corretta per le tue esecuzioni. Per le esecuzioni che non rispondono che utilizzano l'archiviazione statica, valuta la possibilità di aumentare l'allocazione dello storage in esecuzione statica per consentire un throughput I/O e una capacità di archiviazione più elevati sul file system. Analizzate il manifesto di esecuzione per vedere lo spazio di archiviazione massimo del file system, utilizzate Run Analyzer per determinare se è necessario aumentare l'allocazione del file system.

Procedure consigliate per rilevare le esecuzioni che non rispondono

  • Quando sviluppate nuovi flussi di lavoro, utilizzate un gruppo di esecuzione con il limite massimo di tempo di esecuzione impostato per rilevare il codice non funzionante. Ad esempio, se il completamento di un'esecuzione richiede 1 ora, inseriscilo in un gruppo di esecuzioni che scade dopo 2 o 3 ore (o un periodo di tempo diverso in base al caso d'uso) per rilevare i lavori in corso. Inoltre, applica un buffer per tenere conto della varianza nei tempi di elaborazione.

  • Imposta una serie di gruppi di esecuzione con diversi limiti massimi di runtime. Ad esempio, è possibile assegnare esecuzioni brevi a un gruppo di esecuzioni che termina le esecuzioni dopo alcune ore e un gruppo di corse lunghe che termina le esecuzioni dopo alcuni giorni, in base alla durata prevista del flusso di lavoro.

  • HealthOmics ha un limite di servizio per la durata massima di esecuzione predefinito di 604.800 secondi o 7 giorni, regolabile tramite una richiesta nello strumento per le quote. Richiedi un aumento del limite di servizio di questa quota solo se hai corse che durano quasi una settimana. Se disponi di un mix di corse brevi e lunghe e non utilizzi gruppi di corse, valuta la possibilità di inserire le esecuzioni di lunga durata in un account separato con un limite di servizio di durata massima più elevato.

  • Ispeziona il CloudWatch registri per attività che sospetti possano non rispondere. Se un'attività normalmente genera istruzioni di registro regolari e non lo fa per un lungo periodo, è probabile che sia bloccata o bloccata.

Cosa fare se si verifica un'esecuzione che non risponde

  • Annulla la corsa per evitare costi aggiuntivi.

  • Ispeziona il registri delle attività per verificare se alcuni processi non sono riusciti a uscire correttamente.

  • Ispeziona il registri del motore per identificare eventuali comportamenti anomali del motore.

  • Confronta i log delle attività e del motore relativi all'esecuzione che non risponde con quelli delle esecuzioni identiche e completate con successo. Questo può aiutare a identificare eventuali differenze che potrebbero aver causato il comportamento di mancata risposta.

  • Se non riesci a determinare la causa principale, indica un caso di supporto e includere quanto segue:

    • ARN della corsa bloccata e ARN di una corsa identica completata con successo.

    • Registri del motore (disponibili dopo l'annullamento o l'esito negativo dell'esecuzione)

    • Registri delle attività per l'attività che non risponde. Non sono necessari i registri delle attività per tutte le attività del flusso di lavoro per la risoluzione dei problemi.