View a markdown version of this page

Gründe für Ausführungsfehler - AWS HealthOmics
Behebung von INSTANCE_RESERVATION_FAILED-FehlernHinweise für Läufe, die nicht reagieren

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Gründe für Ausführungsfehler

Wenn ein Lauf fehlschlägt, verwenden Sie den GetRun API-Vorgang zum Abrufen der Fehlerursache.

Die Reihenfolge, in der der Ausführungsdatensatz, die Datensätze für fehlgeschlagene Aufgaben und die Protokolle gelesen werden, finden Sie unter Debuggen eines HealthOmics Workflow-Ausführung.

Überprüfe die Fehlerursache, um herauszufinden, warum der Lauf fehlgeschlagen ist. In der folgenden Tabelle sind die einzelnen Fehlergründe zusammen mit einer Beschreibung des Fehlers aufgeführt.

Failure reason (Fehlerursache) Fehlerbeschreibung

ALL_PROFILES_INSTANCE_RESERVATION_FAILED

Es gibt nicht genug Instance-Kapazität für keinen der Beschleuniger, die Sie im omicsResourceFallbackOrder Richtlinie. Erwägen Sie, die Wartezeit für Ressourcen zu verlängern, oder geben Sie alternative Beschleuniger oder eine CPU-Option in Ihrer Fallback-Reihenfolge an. Weitere Informationen zum Ressourcenfallback finden Sie unter Erweiterte Ressourcenkonfiguration.

ASSUME_ROLE_FAILED

HealthOmics hat keine Berechtigung, die Rolle zu übernehmen. Geben Sie den an HealthOmics Principal in der Vertrauensbeziehung für die Rolle.

CONTAINER_ERROR KANN NICHT GESTARTET WERDEN

Workflow-Aufgabe konnte nicht gestartet werden: name, ID: ID Container mit Bild: image name. Vergewissern Sie sich, dass das Bild gültig ist, und versuchen Sie es erneut.

CANNOT_START_CONTAINER_SIZE_ERROR

Workflow-Aufgabe konnte nicht gestartet werden: name, ID: ID Container mit Bild: image name. Stellen Sie sicher, dass die Bildgröße weniger als 45 GiB (95 GiB für eine GPU-Instance) beträgt, und versuchen Sie es erneut.

ECR_IMAGE_NOT_FOUND

Bild wurde unter URI nicht gefunden: uri. Stellen Sie sicher, dass das Image-Tag oder der Digest im Amazon ECR-Repository vorhanden ist, und versuchen Sie es erneut.
ECR_PERMISSION_ERROR

HealthOmics hat keine Berechtigung, auf die Bild-URI zuzugreifen.

Vergewissern Sie sich, dass das private Amazon ECR-Repository existiert und Zugriff auf das gewährt hat HealthOmics Dienstprinzipal.

ECR_REPOSITORY_NICHT_GEFUNDEN

Das Amazon ECR-Repository wurde für den Bild-URI nicht gefunden: uri. Vergewissern Sie sich, dass das Repository existiert und die URI korrekt ist, und versuchen Sie es erneut.

EXPORT_FAILED

Der Export ist fehlgeschlagen. Stellen Sie sicher, dass der Ausgabe-Bucket existiert und die Run-Rolle über Schreibberechtigungen für den Bucket verfügt.

FILE_SYSTEM_OUT_OF_SPACE

 Das Dateisystem hat nicht genug Speicherplatz. Erhöhen Sie die Größe des Dateisystems und führen Sie es erneut aus.

IMAGE_VERIFICATION_FAILURE

Das Bild konnte nicht verifiziert werden image name. Um das Problem zu beheben, versuchen Sie, das Bild abzurufen und es dann erneut in Ihr ECR-Repository zu übertragen.

IMPORT_FEHLGESCHLAGEN

Der Import ist fehlgeschlagen. Stellen Sie sicher, dass die Eingabedatei vorhanden ist und die Ausführungsrolle auf die Eingabe zugreifen kann.
INACTIVE_OMICS_STORAGE_RESOURCE

Die HealthOmics Die Speicher-URI befindet sich nicht im Status AKTIV. Aktivieren Sie das Leseset und versuchen Sie es erneut. Weitere Informationen zur Aktivierung von Lesesätzen finden Sie unter Lesesätze aktivieren in HealthOmics.
EINGABE_URI_NICHT_GEFUNDEN Die angegebene URI existiert nicht: uri. Überprüfen Sie, ob der URI-Pfad existiert, und bestätigen Sie, dass die Rolle auf das Objekt zugreifen kann.

INSTANCE_RESERVATION_FAILED

Es ist nicht genug Instanzkapazität vorhanden, um den Workflow-Lauf abzuschließen. Warten Sie und versuchen Sie erneut, den Workflow auszuführen. Weitere Informationen zur Behebung fehlgeschlagener Fehler bei der Instanzreservierung finden Sie unter Behebung von INSTANCE_RESERVATION_FAILED-Fehlern.
UNGÜLTIGE_ECR_IMAGE-URI

Die Amazon ECR-Image-URI-Struktur ist nicht gültig. Geben Sie eine gültige URI ein und versuchen Sie es erneut.

UNGÜLTIGER_TASK_RESSOURCENWERT

 Die angeforderte GPU, CPU oder Arbeitsspeicher ist entweder zu hoch für die verfügbare Rechenkapazität oder liegt unter dem Mindestwert von 1 für die Aufgabe ID.

UNGÜLTIGE_URI_EINGABE

 Die URI-Struktur ist nicht gültig uri. Überprüfen Sie die URI-Struktur und versuchen Sie es erneut.
MODIFIED_INPUT_RESOURCE

Der angegebene URI uri wurde nach dem Start des Laufs geändert. Versuchen Sie den Lauf erneut.

OUT_OF_MEMORY_ERROR

Die Workflow-Aufgabe ID Der Speicher ging aus. Erhöhen Sie den Speicherwert in der Workflow-Definition und versuchen Sie den Rechenlauf erneut.

RUN_TASK_FAILED

Der Lauf ist fehlgeschlagen, weil die Aufgabe fehlgeschlagen ist. Um den Fehler der Aufgabe zu debuggen, verwenden Sie den GetRunTask API-Betrieb und Amazon CloudWatch Protokolliert den Stream.

RUN_TIMED_OUT

Führen Sie Timeout danach aus number Minuten.
SERVICEFEHLER Im Dienst ist ein vorübergehender Fehler aufgetreten. Versuchen Sie erneut, den Workflow auszuführen.
TASK_TIMED_OUT Aufgabe id hat nachher das Zeitlimit überschritten number Sekunden.

UNSUPPORTED_INPUT_SIZE

Die gesamte Eingabegröße ist zu hoch. Verringern Sie die Eingabegröße und versuchen Sie es erneut.

WORKFLOW_RUN_FAILED

Workflow-Ausführung ist fehlgeschlagen. Überprüfen Sie das CloudWatch Log-Engine-Log-Stream: ID um den Fehler zu debuggen.

WORKFLOW_VER_VALIDATION_FAILED

HealthOmics unterstützt die angeforderte Nextflow-Version nicht: version --. Die neueste unterstützte Version ist version. Ändern Sie Ihre Nextflow-Version auf eine unterstützte Version und versuchen Sie es erneut.

UNSUPPORTED_GPU_INSTANCE_TYPE

Der angeforderte Instanztyp wird in nicht unterstützt Region. Versuchen Sie den Lauf mit einem GPU-Instanztyp, der in dieser Region unterstützt wird. Verfügbare Instanztypen sind GPU instance types.

Behebung von INSTANCE_RESERVATION_FAILED-Fehlern

GPU-Instances sind On-Demand-Ressourcen, die möglicherweise nicht immer sofort in Ihrer bevorzugten Availability Zone oder Region verfügbar sind.

Was HealthOmics macht automatisch

HealthOmics führt in Ihrem Namen mehrere Optimierungen durch, um den Erfolg der GPU-Akquisition zu maximieren:

  • Multi-AZ Suche: HealthOmics prüft mehrere Availability Zones auf GPU-Kapazität, nicht nur eine einzelne AZ.

  • Automatische Wiederholungsversuche: Wenn eine GPU nicht sofort verfügbar ist, HealthOmics versucht mehrmals, Kapazität abzurufen, sobald sie verfügbar ist.

  • GPU-Aufbewahrung bei allen Aufgaben: Wenn Ihr Workflow sequentielle Aufgaben umfasst, für die eine GPU erforderlich ist, HealthOmics behält die GPU, die Sie bereits haben, für nachfolgende Aufgaben bei, anstatt sie freizugeben und erneut anzufordern. So wird der erfolgreiche Abschluss mehrstufiger GPU-Workflows gewährleistet.

Die folgenden zusätzlichen bewährten Methoden können deine Erfolgsquote beim Laufen weiter verbessern GPU-accelerated Workflows aktiviert HealthOmics:

  1. Verwenden Sie Beschleuniger-Pakete, um die Flexibilität zu maximieren

    Anstatt einen bestimmten GPU-Instance-Typ anzufordern, verwenden Sie Accelerator-Pakete, die Folgendes ermöglichen HealthOmics um aus mehreren kompatiblen GPU-Generationen auszuwählen (z. B. g4dn, g5, g6). Je mehr GPU-Typen Ihr Workflow akzeptieren kann, desto höher ist die Wahrscheinlichkeit, verfügbare Kapazität zu finden.

    Weitere Informationen hierzu finden Sie unter Taskbeschleuniger in einem HealthOmics Workflow-Definition. Beispiel:

    • nvidia-t4-a10g-l4 stammt aus den Instance-Familien G4, G5 und G6

    • nvidia-l4-a10g bezieht sich auf G5- und G6-Instanzfamilien

  2. Erwägen Sie, Ihren Workflow in einem anderen auszuführen AWS Region

    Die GPU-Verfügbarkeit variiert je nach AWS Regionen. Wenn deine Anforderungen an den Datenspeicherort dies zulassen, solltest du in Erwägung ziehen, zu rennen GPU-intensive Workflows in einer anderen Region, in der Kapazität möglicherweise leichter verfügbar ist. Weitere Informationen zu den unterstützten Regionen finden Sie unter Servicekontingente und Endpunkte für AWS HealthOmics.

  3. Ressourcen-Fallback konfigurieren

    Für WDL- und Nextflow-Workflows können Sie das verwenden omicsResourceFallbackOrder Direktive zur Definition einer geordneten Liste von Ressourcenprofilen (GPU oder CPU) pro Aufgabe. Wenn Ihr bevorzugter Beschleunigertyp nicht verfügbar ist, HealthOmics probiert automatisch den nächsten Beschleunigertyp oder die nächste CPU aus, anstatt auszufallen. Sie können auch angeben, wie lange HealthOmics sollte nach einer GPU suchen. Zu den Anwendungsfällen zählen:

    • Fallback von GPU zu GPU — probieren Sie zuerst Ihren bevorzugten Beschleuniger aus und greifen Sie dann auf eine Alternative zurück (versuchen Sie es zum Beispiel nvidia-l40s zuerst, dann nvidia-l4).

    • Fallback von GPU zu CPU — füge ein Finale hinzu CPU-only Profil, sodass die Aufgabe abgeschlossen wird, auch wenn keine GPU-Kapazität verfügbar ist.

    Wenn keines der Profile in Ihrer Fallback-Reihenfolge innerhalb der Wartezeit über eine Kapazität verfügt, schlägt der Lauf fehl mit ALL_PROFILES_INSTANCE_RESERVATION_FAILED. Für WDL-Workflows HealthOmics versucht die Aufgabe wegen dieses Fehlers nicht erneut. Für Nextflow-Workflows gilt: errorStrategy und maxRetries stellen Sie fest, ob die Aufgabe erneut versucht wird und ein Wiederholungsversuch erneut mit dem ersten Profil beginnt. Erwägen Sie, die Wartezeit für Ressourcen zu verlängern, oder geben Sie alternative Beschleuniger oder eine CPU-Option in Ihrer Ausweichreihenfolge an.

    Weitere Informationen hierzu finden Sie unter Erweiterte Ressourcenkonfiguration.

Hinweise für Läufe, die nicht reagieren

Bei der Entwicklung neuer Workflows können Läufe oder bestimmte Aufgaben „hängen bleiben“ oder „hängen bleiben“, wenn es Probleme mit Ihrem Code gibt und Aufgaben Prozesse nicht ordnungsgemäß beenden. Es kann schwierig sein, dies zu beheben und zu erkennen, da es normal ist, dass Aufgaben über einen längeren Zeitraum ausgeführt werden. Folgen Sie den empfohlenen bewährten Methoden in den folgenden Abschnitten, um zu verhindern und zu erkennen, dass Ausführungen nicht reagieren.

Bewährte Methoden zur Vermeidung nicht reagierender Läufe

  • Stellen Sie sicher, dass Sie alle in Ihrem Taskcode geöffneten Dateien schließen. Das Öffnen zu vieler Dateien kann gelegentlich zu Threading-Problemen in den Workflow-Engines führen.

  • Hintergrundprozesse, die durch eine Workflow-Aufgabe erstellt wurden, sollten beendet werden, wenn die Aufgabe beendet wird. Wenn ein Hintergrundprozess jedoch nicht ordnungsgemäß beendet wird, müssen Sie diesen Prozess in Ihrem Aufgabencode explizit beenden.

  • Stellen Sie sicher, dass Ihre Prozesse nicht in einer Schleife laufen, ohne sie zu beenden. Dies kann dazu führen, dass ein Lauf nicht mehr reagiert und eine Änderung am Code der Workflow-Definition erforderlich ist, um das Problem zu beheben.

  • Sorgen Sie für eine angemessene Speicher- und CPU-Zuweisung für Ihre Aufgaben. Analysieren Sie die CloudWatch aufzeichnen oder benutze die Führen Sie Analyzer aus bei erfolgreich abgeschlossenen Durchläufen Ihres Workflows, um sicherzustellen, dass Sie die optimale Rechenzuweisung haben. Verwenden Sie den Run Analyzer headroom Parameter, der zusätzlichen Spielraum einbezieht und sicherstellt, dass die Prozesse über genügend Ressourcen verfügen, um sie abzuschließen. Rechnen Sie den zugewiesenen Arbeitsspeicher und die CPU mit mindestens 5% Spielraum aus, um die im Hintergrund ablaufenden Betriebssystemprozesse zu berücksichtigen.

    • Erhöhen Sie außerdem die Bandbreitengröße der Instance, wenn die Instance einen höheren Durchsatz benötigt. Bei Amazon EC2-Instances mit weniger als 16 vCPUs (Größe 4xl und kleiner) kann es zu Durchsatzspitzen kommen. Weitere Informationen zum Durchsatz von Amazon EC2-Instances finden Sie unter Verfügbare Amazon EC2-Instance-Bandbreite.

  • Stellen Sie sicher, dass Sie die richtige Dateisystemgröße für Ihre Läufe verwenden. Bei nicht reagierenden Läufen, die statischen Laufspeicher verwenden, sollten Sie erwägen, die Speicherzuweisung für statische Rechenläufe zu erhöhen, um einen höheren I/O-Durchsatz und eine höhere Speicherkapazität im Dateisystem zu ermöglichen. Analysieren Sie das Run-Manifest, um den maximalen Speicherplatz im Dateisystem zu ermitteln. Verwenden Sie den Run Analyzer, um zu ermitteln, ob die Dateisystemzuweisung erhöht werden muss.

Bewährte Methoden zum Abfangen nicht reagierender Läufe

  • Verwenden Sie bei der Entwicklung neuer Workflows eine Ausführungsgruppe, deren maximale Ausführungszeit festgelegt ist, um außer Kontrolle geratenen Code abzufangen. Wenn eine Ausführung beispielsweise eine Stunde in Anspruch nehmen sollte, ordnen Sie sie einer Ausführungsgruppe zu, die nach 2 oder 3 Stunden (oder je nach Anwendungsfall in einem anderen Zeitraum) das Zeitlimit überschreitet, um außer Kontrolle geratene Jobs abzufangen. Wenden Sie außerdem einen Puffer an, um Abweichungen bei den Verarbeitungszeiten zu berücksichtigen.

  • Richten Sie eine Reihe von Ausführungsgruppen mit unterschiedlichen maximalen Laufzeitlimits ein. Beispielsweise könnten Sie kurze Läufe einer Ausführungsgruppe zuweisen, die die Läufe nach einigen Stunden beendet, und einer Gruppe mit langen Durchläufen, die Läufe nach ein paar Tagen beendet, basierend auf Ihrer erwarteten Workflow-Dauer.

  • HealthOmics hat ein standardmäßiges Service-Limit für die maximale Ausführungsdauer von 604.800 Sekunden oder 7 Tagen, das durch eine Anfrage im Kontingent-Tool angepasst werden kann. Fordern Sie nur dann eine Erhöhung des Servicelimits um dieses Kontingent an, wenn Sie Läufe haben, deren Dauer sich einer Woche nähert. Wenn Sie eine Mischung aus kurzen und langen Läufen haben und keine Run-Gruppen verwenden, sollten Sie erwägen, die Läufe mit langer Laufzeit in einem separaten Konto mit einem höheren Service-Limit für die maximale Laufdauer abzulegen.

  • Untersuchen Sie den CloudWatch aufzeichnen für Aufgaben, von denen Sie vermuten, dass sie nicht reagieren könnten. Wenn eine Aufgabe normalerweise reguläre Protokollanweisungen ausgibt und dies über einen längeren Zeitraum nicht getan wurde, steckt die Aufgabe wahrscheinlich fest oder ist eingefroren.

Was tun, wenn ein Lauf nicht reagiert

  • Brechen Sie den Lauf ab, um zusätzliche Kosten zu vermeiden.

  • Untersuchen Sie das Aufgabenprotokolle um zu überprüfen, ob Prozesse nicht korrekt beendet wurden.

  • Untersuchen Sie das Motorprotokolle um abnormales Motorverhalten zu identifizieren.

  • Vergleichen Sie die Task- und Engine-Protokolle des nicht reagierenden Laufs mit denen identischer, erfolgreich abgeschlossener Läufe. Dies kann helfen, alle Unterschiede zu identifizieren, die möglicherweise dazu geführt haben, dass das Verhalten nicht reagiert.

  • Wenn Sie nicht in der Lage sind, die Ursache zu ermitteln, geben Sie eine Fall unterstützen und beinhalten Folgendes:

    • ARN des hängengebliebenen Laufs und ARN eines identischen Laufs, der erfolgreich abgeschlossen wurde.

    • Engine-Logs (verfügbar, sobald der Lauf abgebrochen wurde oder fehlschlägt)

    • Aufgabenprotokolle für die Aufgabe, die nicht reagiert. Zur Fehlerbehebung benötigen wir keine Aufgabenprotokolle für alle Aufgaben im Workflow.