Motivi di errore dell'esecuzione

Se un'esecuzione non riesce, utilizza l'operazione GetRun API per recuperare il motivo dell'errore.

Rivedi 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.
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:, id: container utilizzando l'immagine:name. ID image name Assicurati che l'immagine sia valida e riprova.
CANNOT_START_CONTAINER_SIZE_ERROR	Impossibile avviare l'attività del flusso di lavoro:, id: container utilizzando l'immagine:. name ID image name Assicurati che la dimensione dell'immagine sia inferiore a 45 GiB (95 GiB per un'istanza GPU) 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 all'entità principale del HealthOmics servizio.
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 trasferiscila nuovamente nel 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	L'URI di archiviazione non è in stato ATTIVO. HealthOmics Attiva il set di lettura e riprova. Per ulteriori informazioni sull'attivazione dei set di lettura, vedereL'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, consultaAttenuazione degli errori INSTANCE_RESERVATION_FAILED.
INVALID_ECR_IMAGE_URI	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 uri fornito è stato modificato dopo l'inizio dell'esecuzione. Riprova a eseguire la corsa.
OUT_OF_MEMORY_ERROR	Memoria esaurita nel task del workflow. ID Aumentate il valore di 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, utilizza l'operazione GetRunTask API e lo stream Amazon CloudWatch Logs.
RUN_TIMED_OUT	Esegui il timeout dopo pochi minuti. number
SERVICE_ERROR	Si è verificato un errore temporaneo nel servizio. Prova a eseguire nuovamente il flusso di lavoro.
TASK_TIMED_OUT	L'attività è scaduta dopo pochi secondi. id number
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. Esamina il flusso di CloudWatch log del motore Logs: 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

Attenuazione 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 fa automaticamente HealthOmics

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.

• Riprove automatiche: quando una GPU non è immediatamente disponibile, HealthOmics riprova più volte per 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 già disponibile 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 nell'esecuzione dei flussi di lavoro su: GPU-accelerated HealthOmics

1. Utilizza i pacchetti di accelerazione per massimizzare la flessibilità

   Invece di richiedere un tipo di istanza GPU specifico, utilizza i bundle di acceleratori che consentono HealthOmics di 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à nella definizione di un flusso di lavoro HealthOmics. Ad esempio:

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

   • nvidia-l4-a10gattinge da famiglie di istanze G5 e G6

2. Valuta la possibilità di eseguire il tuo flusso di lavoro in un'altra regione AWS

   La disponibilità della GPU varia a seconda AWS delle 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. Configura il fallback delle risorse (solo flussi di lavoro WDL)

   Per i flussi di lavoro WDL, la omicsResourceFallbackOrder direttiva consente di definire un elenco ordinato di profili di risorse (GPU o CPU) per attività. Se il tipo di acceleratore preferito non è disponibile, prova HealthOmics automaticamente il tipo di acceleratore o la CPU successiva invece di fallire. Puoi anche specificare per quanto tempo HealthOmics deve essere eseguita la ricerca di una GPU. I casi d'uso includono:

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

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

   Nota

   La omicsResourceFallbackOrder direttiva è attualmente supportata solo per i flussi di lavoro WDL. È previsto il supporto per Nextflow.

   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 tuoi 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 i CloudWatch log o utilizza i dati relativi Esegui Analyzer alle esecuzioni completate con successo del flusso di lavoro per verificare di disporre di un'allocazione di elaborazione ottimale. Utilizzate il headroom parametro Run Analyzer per aggiungere ulteriore margine di manovra, assicurando 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 la larghezza di banda disponibile delle istanze di Amazon EC2. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html#available-instance-bandwidth

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

• Esamina i CloudWatch registri per individuare eventuali attività che ritieni non rispondano. 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 di incorrere in costi aggiuntivi.

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

• Ispeziona i log 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, invia una richiesta di assistenza e includi quanto segue:

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

  • Registri del motore (disponibili una volta che l'esecuzione è stata annullata o fallita)

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