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. |
|---|---|
|
|
La capacità di istanza non è sufficiente per nessuno degli acceleratori specificati in |
|
|
HealthOmics non è autorizzato ad assumere il ruolo. Specifica il HealthOmics principale nella relazione di fiducia per il ruolo. |
|
|
Impossibile avviare l'attività del flusso di lavoro: |
|
|
Impossibile avviare l'attività del flusso di lavoro: |
|
|
Immagine non trovata nell'URI: |
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. |
|
|
Repository Amazon ECR non trovato per l'URI dell'immagine: |
|
|
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. |
|
|
Il file system non dispone di spazio sufficiente. Aumenta le dimensioni del file system ed esegui nuovamente. |
|
|
Impossibile verificare l'immagine |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
La struttura URI non è valida uri. Controlla la struttura dell'URI e riprova. |
MODIFIED_INPUT_RESOURCE |
L'URI fornito |
|
|
L'attività del flusso di lavoro |
|
|
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. |
|
|
Esegui il timeout dopo |
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. |
|
|
La dimensione totale dell'input è troppo alta. Riduci la dimensione dell'input e riprova. |
|
|
Esecuzione del workflow non riuscita. Rivedi il CloudWatch Registra il flusso di log del motore: |
|
|
HealthOmics non supporta la versione Nextflow richiesta: |
|
|
Il tipo di istanza richiesto non è supportato in |
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:
-
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-l4attinge da famiglie di istanze G4, G5 e G6 -
nvidia-l4-a10gattinge da famiglie di istanze G5 e G6
-
-
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.
-
Configurare il fallback delle risorse
Per i flussi di lavoro WDL e Nextflow, puoi usare
omicsResourceFallbackOrderdirettiva 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-l40sprima, poinvidia-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,errorStrategyemaxRetriesdetermina 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
headroomparametro 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.
-