View a markdown version of this page

Gründe für den Ausfall der Ausführung - AWS HealthOmics
Minimierung von INSTANCE_RESERVATION_FAILED-FehlernAnleitung für nicht reagierende Läufe

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 den Ausfall der Ausführung

Wenn ein Lauf fehlschlägt, verwenden Sie den GetRun API-Vorgang, um den Fehlergrund abzurufen.

Überprüfen Sie 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

ASSUME_ROLE_FAILED

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

CONTAINER_ERROR KANN NICHT GESTARTET WERDEN

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

CANNOT_START_CONTAINER_SIZE_ERROR

Workflow-Aufgabe kann nicht gestartet werden:, id: container mit image:. name ID image name Stellen Sie sicher, dass die Bildgröße weniger als 45 GiB (95 GiB für eine GPU-Instanz) beträgt, 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 dem HealthOmics Service Principal Zugriff gewährt hat.

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.

DATEISYSTEM_NICHT GENÜGEND SPEICHERPLATZ

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 Speicher-URI befindet sich nicht im Status ACTIVE. HealthOmics Aktivieren Sie das Leseset und versuchen Sie es erneut. Weitere Informationen zur Aktivierung von Lesesätzen finden Sie unterLesesätze aktivieren HealthOmics.
INPUT_URI_NOT_FOUND Der 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

Die Instanzkapazität reicht nicht aus, um den Workflow-Lauf abzuschließen. Warten Sie und versuchen Sie erneut, den Workflow auszuführen. Weitere Informationen zur Fehlerminimierung bei der Instanzreservierung finden Sie unterMinimierung 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_RESOURCE_VALUE

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.

FEHLER ZU WENIG ARBEITSSPEICHER

Der Workflow-Aufgabe ging der Arbeitsspeicher aus. ID Erhöhen Sie den Speicherwert in der Workflow-Definition und führen Sie die Ausführung erneut aus.

RUN_TASK_FAILED

Der Lauf ist fehlgeschlagen, weil die Aufgabe fehlgeschlagen ist. Verwenden Sie den GetRunTask API-Vorgang und den Amazon CloudWatch Logs-Stream, um den Fehler der Aufgabe zu debuggen.

RUN_TIMED_OUT

Führen Sie den Timeout nach Minuten aus. number
SERVICE_ERROR Im Dienst ist ein vorübergehender Fehler aufgetreten. Versuchen Sie erneut, den Workflow auszuführen.
TASK_TIMED_OUT Bei der Aufgabe ist nach Sekunden ein id Timeout aufgetreten. number

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 den CloudWatch Log-Stream der Logs-Engine:ID, um den Fehler zu debuggen.

WORKFLOW_VER_VALIDATION_FAILED

HealthOmics unterstützt die angeforderte Nextflow-Version nicht: --. version Die neueste unterstützte Version istversion. Ä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 sindGPU instance types.

Minimierung 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 passiert automatisch

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

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

  • Automatische Wiederholungsversuche: Wenn eine GPU nicht sofort verfügbar ist, werden mehrere HealthOmics Versuche wiederholt, um 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, wird die bereits vorhandene GPU für nachfolgende Aufgaben HealthOmics beibehalten, anstatt sie freizugeben und erneut anzufordern. So wird sichergestellt, dass mehrstufige GPU-Workflows erfolgreich abgeschlossen werden.

Die folgenden zusätzlichen Best Practices können Ihre Erfolgsquote bei der Ausführung GPU-accelerated von Workflows auf folgenden Plattformen weiter verbessern: HealthOmics

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

    Anstatt einen bestimmten GPU-Instance-Typ anzufordern, verwenden Sie Beschleuniger-Pakete, mit denen HealthOmics Sie aus mehreren kompatiblen GPU-Generationen auswählen können (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 einer Workflow-Definition HealthOmics. Beispiel:

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

    • nvidia-l4-a10gbezieht sich auf G5- und G6-Instanzfamilien

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

    Die GPU-Verfügbarkeit variiert je nach AWS Region. Wenn Ihre Anforderungen an die Datenresidenz dies zulassen, sollten Sie erwägen, GPU-intensive Workflows in einer anderen Region auszuführen, in der die 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. Ressourcenfallback konfigurieren (nur WDL-Workflows)

    Für WDL-Workflows können Sie mit der omicsResourceFallbackOrder Direktive eine geordnete Liste von Ressourcenprofilen (GPU oder CPU) pro Aufgabe definieren. Wenn Ihr bevorzugter Beschleunigertyp nicht verfügbar ist, versucht es HealthOmics automatisch mit dem nächsten Beschleunigertyp oder der nächsten CPU, anstatt auszufallen. Sie können auch angeben, wie lange nach einer GPU gesucht werden HealthOmics soll. Zu den Anwendungsfällen zählen:

    • GPU-zu-GPU-Fallback — probieren Sie zuerst Ihren bevorzugten Beschleuniger aus und greifen Sie dann auf eine Alternative zurück (z. B. nvidia-l40s zuerst versuchen und dannnvidia-l4).

    • Fallback von GPU zu CPU — fügen Sie ein endgültiges CPU-only Profil hinzu, damit die Aufgabe abgeschlossen wird, auch wenn keine GPU-Kapazität verfügbar ist.

    Anmerkung

    Die omicsResourceFallbackOrder Direktive wird derzeit nur für WDL-Workflows unterstützt. Nextflow-Unterstützung ist geplant.

    Weitere Informationen hierzu finden Sie unter Erweiterte Ressourcenkonfiguration.

Anleitung für nicht reagierende Läufe

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 Protokolle oder verwenden Sie die Führen Sie Analyzer aus Informationen über erfolgreich abgeschlossene Läufe Ihres Workflows, um sicherzustellen, dass die Rechenleistung optimal zugewiesen ist. Verwenden Sie den headroom Parameter Run Analyzer, um zusätzlichen Spielraum einzubeziehen und sicherzustellen, dass die Prozesse über genügend Ressourcen verfügen, um sie abzuschließen. Rechnen Sie mit mindestens 5% Headroom im zugewiesenen Arbeitsspeicher und der CPU 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.

  • Prüfen Sie die CloudWatch Protokolle auf Aufgaben, von denen Sie vermuten, dass sie nicht reagieren. Wenn eine Aufgabe normalerweise regelmäßige Protokollanweisungen ausgibt und dies über einen längeren Zeitraum nicht erfolgt ist, steckt die Aufgabe wahrscheinlich fest oder ist eingefroren.

Was ist zu tun, wenn ein Lauf nicht reagiert

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

  • Prüfen Sie in den https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html#cloudwatch-logs Aufgabenprotokollen, ob Prozesse nicht ordnungsgemäß beendet wurden.

  • Überprüfen Sie die Motorprotokolle, um abnormales Motorverhalten festzustellen.

  • 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 die Ursache nicht ermitteln können, stellen Sie eine Support-Anfrage und fügen Sie Folgendes hinzu:

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