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.
# Verwenden Sie den Run-Cache
Standardmäßig verwenden Läufe keinen Run-Cache. Um einen Cache für die Ausführung zu verwenden, geben Sie den Run-Cache und das Verhalten des Run-Caches an, wenn Sie die Ausführung starten.
Nach Abschluss eines Laufs können Sie die Konsole, CloudWatch Protokolle oder API-Operationen verwenden, um Cache-Treffer zu verfolgen oder Cache-Probleme zu beheben. Details dazu finden Sie unter [Informationen zum Anruf-Caching werden nachverfolgt](#workflow-cache-track) und [Behebung von Problemen beim Zwischenspeichern von Anrufen](troubleshooting.md#workflow-cache-troubleshooting).
Wenn eine oder mehrere Aufgaben in einem Lauf nicht deterministische Ausgaben generieren, empfehlen wir dringend, für die Ausführung kein Aufruf-Caching zu verwenden oder diese speziellen Aufgaben vom Caching auszuschließen. Weitere Informationen finden Sie unter [Modell der geteilten Verantwortung](how-run-cache.md#run-cache-srm).
**Anmerkung**
Sie geben eine IAM-Dienstrolle an, wenn Sie einen Lauf starten. Um Call Caching verwenden zu können, benötigt die Service-Rolle die Erlaubnis, auf den Amazon S3 S3-Standort Run Cache zuzugreifen. Weitere Informationen finden Sie unter [Servicerollen für AWS HealthOmics](permissions-service.md).
Sie können [Amazon Q CLI](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) verwenden, um Ihre Run-Cache-Daten zu analysieren und zu verwalten. Weitere Informationen finden Sie unter [Beispielaufforderungen für Amazon Q CLI](getting-started.md#omics-q-prompts) und im [HealthOmics Agentic Generative AI-Tutorial](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) unter. GitHub
**Topics**
+ [Konfiguration eines Laufs mit Run-Cache mithilfe der Konsole](#workflow-cache-startrun-console)
+ [Konfiguration eines Laufs mit Run-Cache über die CLI](#workflow-cache-startrun-api)
+ [Fehlerfälle bei Run-Caches](#workflow-cache-errors)
+ [Informationen zum Anruf-Caching werden nachverfolgt](#workflow-cache-track)
## Konfiguration eines Laufs mit Run-Cache mithilfe der Konsole
Von der Konsole aus konfigurieren Sie den Run-Cache für einen Lauf, wenn Sie den Lauf starten.
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (±1). Wählen Sie **Läufe** aus.
1. Wählen Sie auf der Seite „**Läufe**“ den Lauf aus, den Sie starten möchten.
1. Wählen Sie **Start run und führen** Sie die Schritte 1 und 2 von **Run starten aus**, wie unter beschrieben[Einen Lauf über die Konsole starten](starting-a-run.md#starting-a-run-console).
1. Wählen Sie in Schritt 3 von **Start Run** die **Option Existierenden Run-Cache auswählen aus**.
1. Wählen Sie den Cache aus der Dropdownliste „**Cache-ID ausführen**“ aus.
1. Um das Standardverhalten beim Ausführen des Cache zu überschreiben, wählen Sie das **Cache-Verhalten** für den Lauf aus. Weitere Informationen finden Sie unter [Verhalten beim Ausführen des Caches](how-run-cache.md#run-cache-behavior).
1. Fahren Sie mit Schritt 4 von **Start Run** fort.
## Konfiguration eines Laufs mit Run-Cache über die CLI
Um einen Lauf zu starten, der einen Run-Cache verwendet, fügen Sie dem CLI-Befehl **start-run** den Parameter cache-id hinzu. Verwenden Sie optional den `cache-behavior` Parameter, um das Standardverhalten zu überschreiben, das Sie für den Run-Cache konfiguriert haben. Das folgende Beispiel zeigt nur die Cache-Felder für den Befehl:
```
aws omics start-run \
...
--cache-id "xxxxxx" \
--cache-behavior CACHE_ALWAYS
```
Wenn der Vorgang erfolgreich ist, erhalten Sie eine Antwort ohne Datenfelder.
## Fehlerfälle bei Run-Caches
In den folgenden Szenarien werden Taskausgaben HealthOmics möglicherweise nicht zwischengespeichert, auch nicht bei einer Ausführung, bei der das Cacheverhalten auf **Immer zwischenspeichern** eingestellt ist.
+ Wenn bei der Ausführung ein Fehler auftritt, bevor die erste Aufgabe erfolgreich abgeschlossen wurde, können keine Cache-Ausgaben exportiert werden.
+ Wenn der Exportvorgang fehlschlägt, werden die Aufgabenausgaben HealthOmics nicht im Amazon S3 S3-Cache gespeichert.
+ Wenn der Lauf aufgrund eines **filesystem out of space** Fehlers fehlschlägt, speichert das Aufruf-Caching keine Aufgabenausgaben.
+ Wenn Sie einen Lauf abbrechen, speichert das Aufruf-Caching keine Aufgabenausgaben.
+ Wenn bei der Ausführung ein Timeout auftritt, speichert das Aufruf-Caching keine Aufgabenausgaben, auch wenn Sie den Lauf so konfiguriert haben, dass bei einem Fehler der Cache verwendet wird.
## Informationen zum Anruf-Caching werden nachverfolgt
Sie können Call-Caching-Ereignisse (z. B. Run-Cache-Treffer) mithilfe der Konsole, der CLI oder CloudWatch Logs verfolgen.
**Topics**
+ [Cache-Treffer mithilfe der Konsole verfolgen](#workflow-cache-track-console)
+ [Verfolgen Sie das Anruf-Caching mit der CLI](#workflow-cache-track-cli)
+ [Verfolgen Sie das Caching von Anrufen mithilfe von Protokollen CloudWatch](#workflow-cache-track-cwl)
### Cache-Treffer mithilfe der Konsole verfolgen
Auf der Seite mit den Ausführungsdetails für einen Lauf werden in der Tabelle **Aufgaben ausführen** Informationen zu **Cache-Treffern** für jede Aufgabe angezeigt. Die Tabelle enthält auch einen Link zum zugehörigen Cache-Eintrag. Gehen Sie wie folgt vor, um die Cache-Trefferinformationen für einen Lauf anzuzeigen.
1. Öffnen Sie die [HealthOmics -Konsole](https://console.aws.amazon.com/omics/).
1. Öffnen Sie bei Bedarf den linken Navigationsbereich (±1). Wählen Sie **Läufe** aus.
1. Wählen Sie auf der Seite „**Läufe**“ den Lauf aus, den Sie überprüfen möchten.
1. Wählen Sie auf der Seite mit den Ausführungsdetails die Registerkarte **Aufgaben ausführen**, um die Tabelle mit den Aufgaben anzuzeigen.
1. Wenn eine Aufgabe einen Cache-Treffer hat, enthält die Spalte **Cache-Treffer** einen Link zum Speicherort des Run-Cache-Eintrags in Amazon S3.
1. Wählen Sie den Link, um den Run-Cache-Eintrag zu überprüfen.
### Verfolgen Sie das Anruf-Caching mit der CLI
Überprüfen Sie mit dem CLI-Befehl **get-run**, ob der Lauf einen Aufrufcache verwendet hat.
```
aws omics get-run --id 1234567
```
Wenn das `cacheId` Feld in der Antwort gesetzt ist, verwendet die Ausführung diesen Cache.
Verwenden Sie den **list-run-tasks**CLI-Befehl, um den Speicherort der Cache-Daten für jede zwischengespeicherte Aufgabe in der Ausführung abzurufen.
```
aws omics list-run-tasks --id 1234567
```
Wenn das Feld CacheHit für eine Aufgabe den Wert true hat, gibt das Feld caches3URI in der Antwort den Speicherort der Cache-Daten für diese Aufgabe an.
Sie können auch den **get-run-task**CLI-Befehl verwenden, um den Cache-Datenspeicherort für eine bestimmte Aufgabe abzurufen:
```
aws omics get-run-task --id 1234567 --task-id
```
### Verfolgen Sie das Caching von Anrufen mithilfe von Protokollen CloudWatch
HealthOmics erstellt Cache-Aktivitätsprotokolle in der `/aws/omics/WorkflowLog` CloudWatch Protokollgruppe. Für jeden Run-Cache gibt es einen Log-Stream: **RunCache//**.
HealthOmics Generiert für Läufe, die Aufruf-Caching verwenden, CloudWatch Log-Einträge für die folgenden Ereignisse:
+ einen Cache-Eintrag erstellen (CACHE\$1ENTRY\$1CREATED)
+ Abgleichen eines Cache-Eintrags (CACHE\$1HIT)
+ konnte mit einem Cache-Eintrag nicht übereinstimmen (CACHE\$1MISS)
Weitere Hinweise zu diesen Protokollen finden Sie unter. [Meldet sich an CloudWatch](monitoring-cloudwatch-logs.md#cloudwatch-logs)
Verwenden Sie die folgende CloudWatch Insights-Abfrage für die `/aws/omics/WorkflowLog` Protokollgruppe, um die Anzahl der Cache-Treffer pro Lauf für diesen Cache zurückzugeben:
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_HIT'
parse "run: *," as run
stats count(*) as cacheHits by run
```
Verwenden Sie die folgende Abfrage, um die Anzahl der Cache-Einträge zurückzugeben, die bei jedem Lauf erstellt wurden:
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_ENTRY_CREATED'
parse "run: *," as run
stats count(*) as cacheEntries by run
```