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.
# Auftragsüberwachung und Debugging
Sie können Kennzahlen zu AWS Glue Jobs sammeln und diese auf den CloudWatch Konsolen AWS Glue und Amazon visualisieren, um Probleme zu identifizieren und zu beheben. Die Profilierung Ihrer AWS Glue-Aufträge erfordert die folgenden Schritte:
1. Metriken aktivieren:
1. Aktivieren der Option **Job metrics (Auftragsmetriken)** in der Auftragsdefinition. Sie können die Profilierung in der AWS Glue-Konsole oder als Parameter für den Auftrag aktivieren. Weitere Informationen finden Sie unter [Definieren von Auftragseigenschaften für Spark-Aufträge](add-job.md#create-job) oder [Verwenden von Auftragsparametern in AWS Glue-Jobs](aws-glue-programming-etl-glue-arguments.md).
1. Aktivieren der Option **AWS Glue-Beobachtbarkeitsmetriken** in der Auftragsdefinition. Sie können die Beobachtbarkeit in der AWS Glue-Konsole oder als Parameter für den Auftrag aktivieren. Weitere Informationen finden Sie unter [Überwachung mit AWS Glue-Beobachtbarkeitsmetriken](monitor-observability.md).
1. Vergewissern Sie sich, dass das Auftragsskript einen `GlueContext` initialisiert. Beispiel: Der folgende Skriptausschnitt initialisiert einen `GlueContext` und zeigt, wo der profilierte Code im Skript platziert wird. Dieses allgemeine Format wird in den folgenden Debugging-Szenarien verwendet.
```
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import time
## @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
...
...
code-to-profile
...
...
job.commit()
```
1. Führen Sie den Auftrag aus.
1. Metriken visualisieren:
1. Sie können die Auftragsmetriken in der AWS Glue-Konsole visualisieren und abnormale Metriken des Treibers oder Executors identifizieren.
1. Überprüfen Sie die Messwerte zur Beobachtbarkeit auf der Seite zur Überwachung von Jobläufen, auf der Seite mit den Details zur Jobausführung oder bei Amazon CloudWatch. Weitere Informationen finden Sie unter [Überwachung mit AWS Glue-Beobachtbarkeitsmetriken](monitor-observability.md).
1. Grenzen Sie die Ursache mithilfe der identifizierten Metrik ein.
1. Optional bestätigen Sie die Ursache mithilfe des Protokollstreams des identifizierten Treibers oder Auftrags-Executors.
**Anwendungsfälle für AWS Glue-Beobachtbarkeitsmetriken**
+ [Debuggen von OOM-Ausnahmen und Auftragsabweichungen](monitor-profile-debug-oom-abnormalities.md)
+ [Debugging von anspruchsvolle Phasen und Straggler-Aufgaben](monitor-profile-debug-straggler.md)
+ [Überwachen des Fortschritts mehrerer Aufträge](monitor-debug-multiple.md)
+ [Überwachung für die DPU-Kapazitätsplanung](monitor-debug-capacity.md)
+ [ Verwenden der AWS Glue-Beobachtbarkeit zur Überwachung der Ressourcennutzung zur Kostensenkung ](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics)
# Debuggen von OOM-Ausnahmen und Auftragsabweichungen
Sie können Ausnahmen und Jobanomalien in out-of-memory (OOM) debuggen. AWS Glue In den folgenden Abschnitten werden Szenarien für das Debuggen von out-of-memory Ausnahmen des Apache Spark-Treibers oder eines Spark-Executors beschrieben.
+ [Debuggen einer OOM-Ausnahme für einen Treiber](#monitor-profile-debug-oom-driver)
+ [Debuggen einer OOM-Ausnahme eines Executors](#monitor-profile-debug-oom-executor)
## Debuggen einer OOM-Ausnahme für einen Treiber
In diesem Szenario liest ein Spark-Auftrag eine große Anzahl von kleinen Dateien von Amazon Simple Storage Service (Amazon S3). Er wandelt die Dateien in das Apache-Parquet-Format um und schreibt sie in Amazon S3. Der Spark-Treiber verfügt nicht mehr über genügend Arbeitsspeicher. Die eingegebenen Amazon-S3-Daten umfassen mehr als 1 Million Dateien in verschiedenen Amazon-S3-Partitionen.
Der profilierte Code sieht wie folgt aus:
```
data = spark.read.format("json").option("inferSchema", False).load("s3://input_path")
data.write.format("parquet").save(output_path)
```
### Visualisieren Sie die profilierten Metriken auf der Konsole AWS Glue
Das folgende Diagramm zeigt die Speicherauslastung als Prozentsatz für den Treiber und Executors. Diese Nutzung wird als ein Datenpunkt dargestellt, gemittelt über die Werte in der letzten Minute. Sie sehen im Speicherprofil des Auftrags, dass der [Speicher für den Treiber](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage) die sichere Schwelle von 50 Prozent Auslastung schnell überschreitet. Zum anderen ist die [durchschnittliche Speicherauslastung](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) für alle Executors nach wie vor kleiner als 4 Prozent. Dies zeigt deutlich Anomalien bei der Treiberausführung in diesem Spark-Auftrag.
![\[Die Speichernutzung in Prozent für den Treiber und Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-memoryprofile.png)
Die Auftragsausführung schlägt schnell fehl und der folgende Fehler wird in der AWS Glue-Konsole auf der Registerkarte **History (Verlauf)** angezeigt: Command Failed mit Exit Code 1 (Fehler mit Exit-Code 1 fehlgeschlagen). Diese Fehlermeldung bedeutet, dass der Auftrag aufgrund eines systemischen Fehlers fehlgeschlagen ist. In diesem Fall steht dem Treiber nicht genügend Arbeitsspeicher zur Verfügung.
![\[Die Fehlermeldung auf der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-errorstring.png)
Wählen Sie auf der Konsole auf der Registerkarte **Verlauf** den Link **Fehlerprotokolle** aus, um zu bestätigen, dass Sie in den CloudWatch Protokollen den Treiber-OOM gefunden haben. Suchen Sie in den Fehlerprotokollen des Auftrags nach "**Error**" (Fehler), um zu bestätigen, dass es tatsächlich eine OOM-Ausnahme war, aufgrund derer der Auftrag fehlgeschlagen ist:
```
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="kill -9 %p"
# Executing /bin/sh -c "kill -9 12039"...
```
Wählen Sie auf der Registerkarte **History (Verlauf)** für den Auftrag die Option **Logs (Protokolle)**. Zu Beginn des Jobs finden Sie in den CloudWatch Protokollen den folgenden Verlauf der Treiberausführung. Der Spark-Treiber versucht, alle Dateien in allen Verzeichnissen aufzulisten, erzeugt einen `InMemoryFileIndex` und startet eine Aufgabe pro Datei. Dies wiederum führt dazu, dass der Spark-Treiber eine große Datenmenge im Arbeitsspeicher halten muss, um den Status aller Aufgaben zu verfolgen. Er speichert die vollständige Liste einer großen Anzahl von Dateien für den In-Memory-Index im Cache, was zu einem OOM-Fehler für den Treiber führt.
### Korrigieren Sie die Verarbeitung von mehreren Dateien unter Verwendung einer Gruppierung
Sie können die Verarbeitung mehrerer Dateien korrigieren, indem Sie die *Gruppierungsfeature* in AWS Glue anwenden. Die Gruppierung wird automatisch aktiviert, wenn Sie dynamische Frames verwenden und wenn das Eingabe-Dataset eine große Anzahl von Dateien (mehr als 50.000) enthält. Die Gruppierung ermöglicht es Ihnen, mehrere Dateien zu einer Gruppe zusammenzufassen, und erlaubt es einer Aufgabe, die gesamte Gruppe statt einer einzelnen Datei zu bearbeiten. Infolgedessen speichert der Spark-Treiber deutlich weniger Status im Speicher, um weniger Aufgaben zu verfolgen. Weitere Informationen zum manuellen Aktivieren der Gruppierung für Ihre Datasets finden Sie unter [Zusammenfassen von Eingabedateien in größeren Gruppen beim Lesen](grouping-input-files.md).
Um das Speicherprofil des AWS Glue-Auftrags zu überprüfen, müssen Sie den folgenden Code mit aktivierter Gruppierung profilieren:
```
df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json")
datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink")
```
Sie können das Speicherprofil und die ETL-Datenbewegung im AWS Glue-Auftragsprofil überwachen.
Der Treiber wird über die gesamte Laufzeit des AWS Glue-Auftrags unterhalb der Schwelle von 50 Prozent Speicherverbrauch ausgeführt. Die Executors streamen die Daten von Amazon S3, verarbeiten sie und schreiben sie in Amazon S3. Dadurch verbrauchen sie zu jedem Zeitpunkt weniger als 5 Prozent Speicherplatz.
![\[Das Speicherprofil zeigt, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-memoryprofile-fixed.png)
Das folgende Datenbewegungsprofil zeigt die Gesamtzahl der Amazon-S3-Bytes, die beim Auftragsfortschritt in der letzten Minute von allen Executors [gelesen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) und [geschrieben](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) wurden. Beide folgen einem ähnlichen Muster, da die Daten über alle Executors gestreamt werden. Der Auftrag verarbeitet alle eine Million Dateien in weniger als drei Stunden.
![\[Das Datenbewegungsprofil zeigt, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-etlmovement.png)
## Debuggen einer OOM-Ausnahme eines Executors
In diesem Szenario erfahren Sie, wie Sie OOM-Ausnahmen debuggen, die in Apache Spark Executors auftreten können. Der folgende Code verwendet den Spark MySQL-Reader, um eine große Tabelle mit etwa 34 Millionen Zeilen in einen Spark DataFrame einzulesen. Anschließend schreibt es ihn im Parquet-Format in Amazon S3. Sie können die Verbindungseigenschaften angeben und die Standardkonfigurationen von Spark verwenden, um die Tabelle zu lesen.
```
val connectionProperties = new Properties()
connectionProperties.put("user", user)
connectionProperties.put("password", password)
connectionProperties.put("Driver", "com.mysql.jdbc.Driver")
val sparkSession = glueContext.sparkSession
val dfSpark = sparkSession.read.jdbc(url, tableName, connectionProperties)
dfSpark.write.format("parquet").save(output_path)
```
### Visualisieren der profilierten Metriken auf der AWS Glue-Konsole
Wenn die Steigung des Speicherauslastungsdiagramms positiv ist und 50 Prozent überschreitet und der Auftrag fehlschlägt, bevor die nächste Metrik ausgegeben wird, wird dies wahrscheinlich durch aufgebrauchten Speicher verursacht. Das folgende Diagramm zeigt, dass innerhalb einer Minute der Ausführung die [durchschnittliche Speicherauslastung](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) in allen Executors schnell über 50 Prozent steigt. Die Nutzung erreicht bis zu 92 Prozent und der Container, der den Executor ausführt, wird von Apache Hadoop YARN beendet.
![\[Die durchschnittliche Speicherauslastung in allen Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile.png)
Wie die folgende Grafik zeigt, wird immer ein [einzelner Executor](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors) ausgeführt, bis der Auftrag fehlschlägt. Dies liegt daran, dass ein neuer Executor gestartet wird, um den beendeten Executor zu ersetzen. Die Lesevorgänge der JDBC-Datenquelle sind standardmäßig nicht parallelisiert, da dies eine Partitionierung der Tabelle für eine Spalte und das Öffnen mehrerer Verbindungen erforderlich machen würde. Dies bewirkt, dass nur ein Executor die vollständige Tabelle sequenziell liest.
![\[Die Auftragsausführung zeigt, dass ein einzelner Executor aktiv ist, bis der Auftrag fehlschlägt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-execution.png)
Wie die folgende Grafik zeigt, versucht Spark viermal, eine neue Aufgabe zu starten, bevor der Auftrag fehlschlägt. Sie sehen das [Speicherprofil](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.used) von drei Executors. Jeder Executor verbraucht schnell seinen gesamten Arbeitsspeicher. Der vierte Executor hat nicht mehr genügend Speicherplatz, und der Auftrag schlägt fehl. Aus diesem Grund wird die Metrik nicht sofort gemeldet.
![\[Die Speicherprofile der Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-exec-memprofile.png)
Sie können anhand der Fehlerzeichenfolge auf der AWS Glue-Konsole bestätigen, dass der Auftrag aufgrund von OOM-Ausnahmen fehlgeschlagen ist, wie im folgenden Bild gezeigt.
![\[Die Fehlermeldung auf der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-errorstring.png)
**Jobausgabeprotokolle:** Weitere Informationen zur Bestätigung Ihrer Feststellung einer Executor-OOM-Ausnahme finden Sie in den CloudWatch Protokollen. Wenn Sie nach **Error** suchen, finden Sie zuerst die vier Executors, die etwa in denselben Zeitfenstern beendet wurden, wie auf dem Metriken-Dashboard gezeigt. Alle werden von YARN beendet, wenn sie ihre Speicherlimits überschreiten.
Executor 1
```
18/06/13 16:54:29 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 ERROR YarnClusterScheduler: Lost executor 1 on ip-10-1-2-175.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:54:29 WARN TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, ip-10-1-2-175.ec2.internal, executor 1): ExecutorLostFailure (executor 1 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Executor 2
```
18/06/13 16:55:35 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 ERROR YarnClusterScheduler: Lost executor 2 on ip-10-1-2-16.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:55:35 WARN TaskSetManager: Lost task 0.1 in stage 0.0 (TID 1, ip-10-1-2-16.ec2.internal, executor 2): ExecutorLostFailure (executor 2 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Executor 3
```
18/06/13 16:56:37 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 ERROR YarnClusterScheduler: Lost executor 3 on ip-10-1-2-189.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:56:37 WARN TaskSetManager: Lost task 0.2 in stage 0.0 (TID 2, ip-10-1-2-189.ec2.internal, executor 3): ExecutorLostFailure (executor 3 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
Executor 4
```
18/06/13 16:57:18 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 ERROR YarnClusterScheduler: Lost executor 4 on ip-10-1-2-96.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
18/06/13 16:57:18 WARN TaskSetManager: Lost task 0.3 in stage 0.0 (TID 3, ip-10-1-2-96.ec2.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead.
```
### Korrigieren der Einstellung der Abrufgröße unter Verwendung dynamischer AWS Glue-Frames
Der Executor hatte beim Lesen der JDBC-Tabelle keinen Speicher mehr zur Verfügung, da die Standardkonfiguration für die Spark JDBC-Abrufgröße Null ist. Dies bedeutet, dass der JDBC-Treiber auf dem Spark Executor versucht, die 34 Millionen Zeilen aus der Datenbank zusammen abzurufen und zwischenzuspeichern, obwohl Spark die Zeilen einzeln durchläuft. Mit Spark können Sie dieses Szenario zu vermeiden, indem Sie den Parameter für die Abrufgröße auf einen Standardwert ungleich Null setzen.
Sie können dieses Problem auch beheben, indem Sie stattdessen dynamische AWS Glue-Frames verwenden. Dynamische Frames verwenden standardmäßig eine Abrufgröße von 1.000 Zeilen. Dieser Wert ist in der Regel ausreichend. Dies bewirkt, dass der Executor nicht mehr als 7 Prozent des gesamten Speichers verbraucht. Der AWS Glue-Auftrag wird in weniger als zwei Minuten mit nur einem einzigen Executor ausgeführt. Dies wird während die Verwendung von dynamischen Frames von AWS Glue als Ansatz empfohlen. Es ist aber auch möglich, eine Abrufgröße mit der Apache-Spark-Eigenschaft `fetchsize` festzulegen. Weitere Informationen finden Sie im [Spark SQL DataFrames and Datasets Guide](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html#jdbc-to-other-databases).
```
val (url, database, tableName) = {
("jdbc_url", "db_name", "table_name")
}
val source = glueContext.getSource(format, sourceJson)
val df = source.getDynamicFrame
glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink")
```
**Normal profilierte Metriken:** Der [Executor-Speicher](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) mit dynamischen AWS Glue-Frames übersteigt nie den sicheren Schwellenwert, wie in der folgenden Abbildung dargestellt. Er streamt die Zeilen aus der Datenbank und speichert jeweils nur 1.000 Zeilen im JDBC-Treiber. Es tritt keine Ausnahme aufgrund von Speichermangel auf.
![\[Die AWS Glue-Konsole zeigt, dass der Executor-Speicher unter der sicheren Schwelle liegt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile-fixed.png)
# Debugging von anspruchsvolle Phasen und Straggler-Aufgaben
Mit dem AWS Glue-Aufgabenprofiling können Sie anspruchsvolle Phasen und Straggler-Aufgaben in Ihren ETL-Aufträgen (Extrahieren, Transformieren und Laden) identifizieren. Eine Straggler-Aufgabe dauert viel länger als der Rest der Aufgaben in einer Phase eines AWS Glue-Auftrags. Dies bewirkt, dass die Phase länger dauert, was auch die gesamte Ausführungszeit des Auftrags verzögert.
## Zusammenführung von kleinen Eingabedateien zu größeren Ausgabedateien
Eine Straggler-Aufgabe kann auftreten, wenn eine uneinheitliche Verteilung der Arbeit auf die verschiedenen Aufgaben gibt, oder wenn eine Datenverzerrung dazu führt, dass eine Aufgabe mehr Daten verarbeiten muss.
Sie können den folgenden Code profilieren (ein gemeinsames Muster in Apache Spark), um eine große Anzahl von kleinen Dateien zu größeren Ausgabedateien zusammenzuführen. In diesem Beispiel besteht das Eingabe-Dataset aus 32 GB mit Gzip komprimierten JSON-Dateien. Das Ausgabe-Dataset umfasst ca. 190 GB nicht komprimierte JSON-Dateien.
Der profilierte Code sieht wie folgt aus:
```
datasource0 = spark.read.format("json").load("s3://input_path")
df = datasource0.coalesce(1)
df.write.format("json").save(output_path)
```
### Visualisieren der profilierten Metriken auf der AWS Glue-Konsole
Sie können Ihren Auftrags profilieren, um vier verschiedene Metrik-Gruppen zu überprüfen:
+ ETL-Datenbewegung
+ Datenmischung über Executors hinweg
+ Auftragsausführung
+ Arbeitsspeicherprofil
**ETL-Datenbewegung**: Im Profil **ETL Data Movement (ETL-Datenbewegung)** werden die Bytes von allen Executors in der ersten Phase, die innerhalb der ersten sechs Minuten abgeschlossen wird, relativ schnell [gelesen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes). Die gesamte Auftragsausführung dauert jedoch etwa eine Stunde, vor allem durch die [Schreibvorgänge](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) für die Daten.
![\[Graph, der das Profil der ETL-Datenbewegung zeigt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-1.png)
**Datenmischung über Executors hinweg:** Die Anzahl der [gelesenen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead) und [geschriebenen Bytes](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten) während des Mischens zeigt auch eine hohe Zahl, bevor Phase 2 endet, wie durch die Metriken **Job Execution (Auftragsausführung)** und **Data Shuffle (Datenmischung)** gezeigt. Nachdem die Daten aus allen Executors gemischt wurden, werden die Lese- und Schreiboperationen nur noch von Executor Nummer 3 ausgeführt.
![\[Die Metriken für das Mischen der Daten über alle Executors hinweg.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-2.png)
**Auftragsausführung:** Wie im folgenden Graphen gezeigt, sind alle anderen Executors im Leerlauf und werden schließlich zum Zeitpunkt 10:09 aufgegeben. Zu diesem Zeitpunkt verringert sich die Gesamtanzahl der Executors auf nur einen. Dies zeigt deutlich, dass der Executor Nummer 3 aus der Straggler-Aufgabe besteht, die die längste Ausführungszeit benötigt und zum größten Teil zur Auftragsausführungszeit beiträgt.
![\[Die Ausführungs-Metriken für die aktiven Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-3.png)
**Speicherprofil:** Nachdem den ersten beiden Phasen verbraucht nur noch [Executor Nummer 3](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) aktiv Arbeitsspeicher zur Verarbeitung der Daten. Die restlichen Executors sind einfach im Leerlauf oder wurden kurz nach Abschluss der ersten beiden Phasen aufgegeben.
![\[Die Metriken für das Arbeitsspeicherprofil nach der ersten zwei Phasen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-4.png)
### Beheben von Straggling-Executors unter Verwendung der Gruppierung
Mit der *Gruppierungsfeature* in AWS Glue können Sie Straggling-Executors vermeiden. Verwenden Sie die Gruppierung, um die Daten gleichmäßig auf alle Executors zu verteilen und Dateien zu größeren Dateien zusammenzufassen, indem Sie alle verfügbaren Executors auf dem Cluster verwenden. Weitere Informationen finden Sie unter [Zusammenfassen von Eingabedateien in größeren Gruppen beim Lesen](grouping-input-files.md).
Um die ETL-Datenbewegungen des AWS Glue-Auftrags zu überprüfen, müssen Sie den folgenden Code mit aktivierter Gruppierung profilieren:
```
df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json")
datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "json", transformation_ctx = "datasink4")
```
**ETL-Datenbewegung:** Die Datenschreibvorgänge werden nun parallel zu den Datenlesevorgängen während der gesamten Ausführungszeit des Auftrags gestreamt. Dies bewirkt, dass der Auftrag innerhalb von acht Minuten abgeschlossen wird, viel schneller als zuvor.
![\[Die ETL-Datenbewegungen zeigen, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-5.png)
**Datenmischung über Executors hinweg:** Da die Eingabedateien während des Lesens über die Gruppierungsfeature zusammengeführt werden, gibt es nach dem Lesen der Daten keine kostspielige Datenmischung.
![\[Die Metriken zur Datenmischung zeigen, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-6.png)
**Auftragsausführung:** Die Auftragsausführungsmetriken zeigen, dass die Gesamtanzahl der aktiven Executors, die ausgeführt werden und Daten verarbeiten, relativ konstant bleibt. Es gibt keine einzelnen Straggler in dem Auftrag. Alle Executors sind aktiv und werden nicht aufgegeben, bis zum der Auftrag abgeschlossen ist. Da es keine zwischenzeitliche Datenmischung zwischen den Executors gibt, gibt es nur eine einzige Phase in dem Auftrag.
![\[Das Widget mit den Metriken für die Auftragsausführung zeigt, dass keine Straggler im Auftrag vorhanden sind.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-7.png)
**Speicherprofil:** Die Metriken zeigen die [aktive Speicherbelegung](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) für alle Executors – dies bestätigt, dass Aktivitäten auf allen Executors vorliegen. Da die Daten parallel gestreamt und ausgegeben werden, ist der gesamte Speicherbedarf aller Executors etwa gleich groß und liegt weit unter der sicheren Schwelle für alle Executors.
![\[Die Speicherprofilmetriken zeigen die aktive Speicherbelegung über alle Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-8.png)
# Überwachen des Fortschritts mehrerer Aufträge
Sie können mehrere AWS Glue Jobs zusammen profilieren und den Datenfluss zwischen ihnen überwachen. Dies ist ein gängiges Workflow-Muster und erfordert die Überwachung des Fortschritts einzelner Aufträge, des Datenverarbeitungsrückstands, der Datenwiederaufbereitung und der Auftragslesezeichen.
**Topics**
+ [Profilierter Code](#monitor-debug-multiple-profile)
+ [Visualisieren der profilierten Metriken auf der AWS Glue-Konsole](#monitor-debug-multiple-visualize)
+ [Korrektur der Dateiverarbeitung](#monitor-debug-multiple-fix)
## Profilierter Code
In diesem Workflow haben Sie zwei Aufträge: einen Eingangsauftrag und einen Ausgangsauftrag. Die Ausführung des Eingangsauftrags ist für alle 30 Minuten eingeplant, wofür ein regelmäßiger Auslöser verwendet wird. Die Ausführung des Ausgangsauftrags ist nach jeder erfolgreichen Ausführung des Eingangsauftrags eingeplant. Diese geplanten Aufträge werden unter Verwendung von Auftragsauslöser kontrolliert.
![\[Screenshot der Konsole mit den Auftragsauslösern, die die Einplanung von Eingangs- und Ausgangsaufträgen kontrollieren.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-1.png)
**Eingangsauftrag**: Dieser Auftrag liest Daten von einem Amazon Simple Storage Service (Amazon S3)-Speicherort, transformiert sie mit `ApplyMapping` und schreibt sie an einen Amazon-S3-Staging--Speicherort. Der folgende Code ist profilierter Code für den Eingangsauftrag:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": ["s3://input_path"], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": staging_path, "compression": "gzip"}, format = "json")
```
**Ausgangsauftrag**: Dieser Auftrag liest die Ausgabe des Eingangsauftrags vom Staging-Speicherort in Amazon S3, transformiert sie wieder und schreibt sie an ein Ziel:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "json")
```
## Visualisieren der profilierten Metriken auf der AWS Glue-Konsole
Das folgende Dashboard überlagert die geschriebenen Bytes der Amazon-S3-Metrik vom Eingangsauftrag mit den gelesenen Bytes der Amazon-S3-Metrik auf derselben Zeitachse für den Ausgangsauftrag. Die Zeitachse zeigt verschiedenen Auftragsausführungen der Eingangs- und Ausgangsaufträge. Der Eingangsauftrag (rot markiert) startet alle 30 Minuten. Der Ausgangsauftrag (braun dargestellt) beginnt bei Abschluss des Eingangsauftrags mit einer maximalen Nebenläufigkeit von 1.
![\[Graph, der die gelesenen und geschriebenen Daten zeigt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-4.png)
In diesem Beispiel sind die [Auftragslesezeichen](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html) nicht aktiviert. Es werden keine Transformationskontexte verwendet, um Auftragslesezeichen im Skriptcode zu aktivieren.
**Job History (Auftragsverlauf)**: Die Eingangs- und Ausgangsaufträge haben mehrere Ausführungen, wie auf der Registerkarte **History (Verlauf)** gezeigt, beginnend um 12:00 PM.
Der Eingangsauftrag in der AWS Glue-Konsole sieht wie folgt aus:
![\[Screenshot der Konsole mit der Registerkarte History (Verlauf) des Eingangsauftrags.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-2.png)
Das folgende Bild zeigt den Ausgangsauftrag:
![\[Screenshot der Konsole mit der Registerkarte History (Verlauf) des Ausgangsauftrags.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-3.png)
**First job runs (Erste Auftragsausführungen)**: Wie im folgenden Graphen für gelesene und geschriebene Datenbytes dargestellt, zeigen die ersten Auftragsausführungen der Eingangs- und Ausgangsaufträge zwischen 12:00 und 12:30 Uhr ungefähr die gleiche Fläche unter den Kurven. Diese Flächen stellen die vom Eingangsauftrag geschriebenen Amazon-S3-Bytes und die vom Ausgangsauftrag gelesenen Amazon-S3-Bytes dar. Diese Daten werden auch durch das Verhältnis von geschriebenen Amazon-S3-Bytes (summiert über 30 Minuten – die Auftragsauslösefrequenz für den Eingangsauftrag) bestätigt. Der Datenpunkt für das Verhältnis für die Eingangsauftragsausführung, die um 12:00 Uhr PM gestartet wurde, ist ebenfalls 1.
Der folgende Graph zeigt das Datenflussverhältnis für alle Auftragsausführungen:
![\[Graph, der das Datenflussverhältnis zeigt: geschriebenen Bytes und gelesene Bytes.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-5.png)
**Second job runs (Zweite Auftragsausführungen)**: In der zweiten Auftragsausführung gibt es eine klare Differenz zwischen der Anzahl der vom Ausgangsauftrag gelesenen Bytes im Vergleich zu der Anzahl der vom Eingangsauftrag geschriebenen Bytes. (Vergleichen Sie die Fläche unter der Kurve der beiden Auftragsausführungen für den Ausgangsauftrag oder vergleichen Sie die Flächen der zweiten Ausführung der Eingangs- und Ausgangsaufträge.) Das Verhältnis der gelesenen und geschriebenen Bytes zeigt, dass der Ausgangsauftrag in der zweiten Spanne von 30 Minuten von 12:30 bis 13:00 Uhr etwa die 2,5-fache Menge der vom Eingangsauftrag geschriebenen Daten gelesen hat. Der Grund hierfür ist, dass der Ausgangsauftrag die Ausgabe der ersten Auftragsausführung des Eingangsauftrags erneut verarbeitet hat, weil keine Auftragslesezeichen aktiviert waren. Ein Verhältnis von über 1 zeigt, dass es einen zusätzlichen Rückstand an Daten gibt, die von dem Ausgangsauftrag verarbeitet wurde.
**Third job runs (Dritte Auftragsausführungen)**: Der Eingangsauftrag ist relativ konsistent in Bezug auf die Anzahl der geschriebenen Bytes (siehe Fläche unter der roten Kurven). Die dritte Auftragsausführung des Eingangsauftrags ist jedoch länger gelaufen als erwartet (siehe langer Auslauf der roten Kurve). Dies hat zur Folge, dass die dritte Auftragsausführung des Ausgangsauftrags zu spät gestartet wurde. Die dritte Auftragsausführung verarbeitet nur ein Bruchteil der akkumulierten Daten am Staging-Speicherort in den verbleibenden 30 Minuten zwischen 13:00 und 13:30 Uhr. Das Verhältnis des Bytestroms zeigt, dass sie nur 0,83 der von der dritten Auftragsausführung des Eingabeauftrags geschriebenen Daten verarbeitet hat (siehe Verhältnis um 13.00 Uhr).
**Overlap of Input and Output jobs (Überlappende Eingangs- und Ausgangsaufträge)**: Die vierte Auftragsausführung des Eingangsauftrags startete um 13:30 gemäß den Zeitplan, bevor die dritte Auftragsausführung des Ausgangsauftrags abgeschlossen wurde. Es gibt eine partielle Überschneidung zwischen diesen beiden Auftragsausführungen. Die dritte Auftragsausführung des Ausgangsauftrags erfasst nur die Dateien, die am Staging-Speicherort von Amazon S3 aufgelistet sind, als sie etwa um 13:17 Uhr begonnen hat. Dies umfasst alle Datenausgaben aus den ersten Auftragsausführungen des Eingangsauftrags. Das tatsächliche Verhältnis um 13:30 ist etwa 2,75. Die dritte Auftragsausführung des Ausgangsauftrags hat etwa das 2,75-fache der von der vierten Auftragsausführung von 13:30 bis 14:00 Uhr geschriebenen Daten verarbeitet.
Wie diese Bilder zeigen, verarbeitet der Ausgangsauftrag Daten vom Staging-Standort aus allen vorherigen Auftragsausführungen des Eingangsauftrags erneut. Dies hat zur Folge, dass die vierte Auftragsausführung für den Ausgangsauftrag die längste ist und sich mit der gesamten fünften Auftragsausführung des Eingangsauftrags überlappt.
## Korrektur der Dateiverarbeitung
Sie sollten sicherstellen, dass der Ausgangsauftrag nur die Dateien verarbeitet, die von den vorherigen Auftragsausführungen des Ausgangsauftrags nicht verarbeitet wurden. Dazu aktivieren Sie die Auftragslesezeichen und legen Sie den Transformationskontext im Ausgangsauftrag wie folgt fest:
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json", transformation_ctx = "bookmark_ctx")
```
Bei aktivierten Auftragslesezeichen verarbeitet der Ausgangsauftrag die Daten am Staging-Speicherort aus allen vorherigen Auftragsausführungen des Eingangsauftrags nicht erneut. In der folgenden Abbildung mit den gelesenen und geschriebenen Daten ist die Fläche unter der braunen Kurve relativ konsistent und ähnlich den roten Kurven.
![\[Graph, der die gelesenen und geschriebenen Daten als rote und braune Linien zeigt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-6.png)
Auch die Verhältnisse des Byteflusses bleiben etwa bei 1, da keine zusätzlichen Daten verarbeitet werden.
![\[Graph, der das Datenflussverhältnis zeigt: geschriebenen Bytes und gelesene Bytes\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-7.png)
Eine Auftragsausführung für den Ausgangsauftrag startet und erfasst die Dateien am Staging-Speicherort, bevor die nächste Eingangsauftragsausführung gestartet wird, womit weitere Daten am Staging-Standort abgelegt werden. Solange dies fortgesetzt wird, verarbeitet sie nur die Dateien, die von der vorherigen Eingangsauftragsausführung erfasst wurden, und das Verhältnis bleibt etwa 1.
![\[Graph, der das Datenflussverhältnis zeigt: geschriebenen Bytes und gelesene Bytes\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-7.png)
Angenommen, der Eingangsauftrag dauert länger als erwartet, und der Ausgangsauftrag erfasst aus diesem Grund Dateien am Staging-Standort von zwei Eingangsauftragsausführungen. Das Verhältnis wird dann höher als 1 für diese Ausgangsauftragausführung. Die folgenden Auftragsausführungen des Ausgangsauftrags verarbeiten jedoch keine Dateien, die bereits von den vorherigen Auftragsausführungen des Ausgangsauftrags verarbeitet wurden.
# Überwachung für die DPU-Kapazitätsplanung
Sie können Job-Metriken verwenden AWS Glue , um die Anzahl der Datenverarbeitungseinheiten (DPUs) zu schätzen, die zur Skalierung eines AWS Glue Jobs verwendet werden können.
**Anmerkung**
Diese Seite trifft nur auf AWS Glue-Versionen 0.9 und 1.0 zu. Spätere Versionen von AWS Glue enthalten Funktionen zur Kosteneinsparung, die zusätzliche Überlegungen bei der Kapazitätsplanung mit sich bringen.
**Topics**
+ [Profilierter Code](#monitor-debug-capacity-profile)
+ [Visualisieren der profilierten Metriken auf der AWS Glue-Konsole](#monitor-debug-capacity-visualize)
+ [Bestimmen der optimalen DPU-Kapazität](#monitor-debug-capacity-fix)
## Profilierter Code
Das folgende Skript liest eine Amazon Simple Storage Service (Amazon S3)-Partition mit 428 gezippten JSON-Dateien. Das Skript wendet ein Mapping an, um die Feldnamen zu ändern, und konvertiert und schreibt sie in Amazon S3 im Apache-Parquet-Format. Sie stellen 10 DPUs standardmäßig bereit und führen diesen Job aus.
```
datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [input_path], "useS3ListImplementation":True,"recurse":True}, format="json")
applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [(map_spec])
datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet")
```
## Visualisieren der profilierten Metriken auf der AWS Glue-Konsole
**Job-Run 1:** In diesem Job-Run zeigen wir, wie Sie herausfinden können, ob DPUs im Cluster zu wenig Provisioning vorhanden ist. Die Auftragsausführungsfunktionalität in AWS Glue zeigt die [Gesamtzahl der aktiven Executors](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors), die [Anzahl der abgeschlossenen Phasen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages) und die [Anzahl der maximal benötigten Executors](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors).
Die Anzahl der maximal benötigten Executors wird berechnet, indem die Gesamtzahl der laufenden Aufgaben und anstehenden Aufgaben addiert und durch die Aufgaben pro Executor dividiert wird. Dieses Ergebnis ist ein Maß für die Gesamtanzahl der Executors, die erforderlich sind, um die aktuelle Last zu erfüllen.
Im Gegensatz dazu misst die Anzahl der aktiven Executors, wie viele aktive Apache-Spark-Aufgaben ausgeführt werden. Im weiteren Verlauf des Auftrags können sich die maximal benötigten Executors ändern und gehen in der Regel gegen Ende des Auftrags zurück, da die Warteschlange der anstehenden Aufgaben abnimmt.
Die horizontale rote Linie in der folgenden Grafik zeigt die Anzahl der maximal zugewiesenen Executoren, die von der Anzahl der Executoren abhängt, DPUs die Sie dem Job zuweisen. In diesem Fall weisen Sie dem ausgeführten Job 10 DPUs zu. Eine DPU ist für die Verwaltung reserviert. Neun DPUs führen jeweils zwei Executors aus und ein Executor ist für den Spark-Treiber reserviert. Der Spark-Treiber wird in der primären Anwendung ausgeführt. Die Anzahl der maximalen zugewiesenen Executors ist also 2\$1 9 – 1 = 17 Executors.
![\[Die Auftragsmetriken, die die aktiven Executors und die maximal benötigten Executors zeigen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-1.png)
Wie der Graph zeigt, beginnt die Anzahl der maximal benötigten Executors bei 107 zu Beginn des Auftrags, während die Anzahl der aktiven Executors bei 17 bleibt. Dies entspricht der Anzahl der maximal zugewiesenen Executoren mit 10. DPUs Das Verhältnis zwischen den maximal benötigten Executors und den maximal zugewiesenen Executors (zu beiden wird für den Spark-Treiber 1 addiert) ergibt den Faktor für die zu niedrig ausgelegte Bereitstellung: 108/18 = 6x. Sie können 6 (unter dem Provisioning Ratio) \$19 (aktuelle DPU-Kapazität — 1) \$1 1 DPUs = 55 bereitstellen, um den Job so DPUs zu skalieren, dass er mit maximaler Parallelität ausgeführt und schneller abgeschlossen wird.
Die AWS Glue -Konsole zeigt die detaillierten Auftragsmetriken als statische Linie an, die die ursprüngliche Anzahl der maximal zugeteilten Executors darstellt. Die Konsole berechnet die maximal zugeteilten Executors aus der Auftragsdefinition für die Metriken. Im Gegensatz dazu berechnet die Konsole für detaillierte Messwerte zur Auftragsausführung die maximal zugewiesenen Executoren aus der Job-Run-Konfiguration, insbesondere die für die Job-Ausführung zugewiesenen. DPUs Um Metriken für eine einzelne Auftragsausführung anzuzeigen, wählen Sie die Auftragsausführung und anschließend **View run metrics (Ausführungsmetriken anzeigen)** aus.
![\[Die Auftragsmetriken, die die ETL-Datenbewegung zeigen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-2.png)
Bei der Betrachtung der [gelesenen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) und [geschriebenen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) Amazon-S3-Bytes erkennen Sie, dass der Auftrag alle sechs Minuten parallel Daten aus Amazon S3 streamt und schreibt. Alle Kerne auf den zugewiesenen DPUs Kernen lesen und schreiben in Amazon S3. Die maximale Anzahl an benötigten Executors von 107 entspricht auch der Anzahl der Dateien im Amazon-S3-Eingangspfad 428. Jeder Executor können vier Spark-Aufgaben zur Verarbeitung von vier Eingangsdateien (gezippte JSON-Dateien) starten.
## Bestimmen der optimalen DPU-Kapazität
Basierend auf den Ergebnissen der vorherigen Auftragsausführung können Sie die Gesamtzahl der zugewiesenen Aufgaben DPUs auf 55 erhöhen und so die Leistung des Auftrags überprüfen. Der Auftrag wird in weniger als drei Minuten abgeschlossen – der Hälfte der Zeit, die zuvor erforderlich war. Die Auftragsskalierung erfolgt in diesem Fall nicht linear, da es sich um einen kurzen Auftrag handelt.. Jobs mit langlebigen Aufgaben oder einer großen Anzahl von Aufgaben (eine große Anzahl von maximal benötigten Executoren) profitieren von einer close-to-linear DPU-Scale-Out-Leistungssteigerung.
![\[Grafik, die die Zunahme der Gesamtzahl der zugewiesenen Aufgaben zeigt DPUs\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-3.png)
Wie die folgende Abbildung zeigt, erreicht die Gesamtzahl der aktiven Executors die maximale Anzahl zugewiesener Executors107. Ebenso liegt die maximale Anzahl benötigter Executors nie über den maximal zugewiesenen Executors. Die maximale Anzahl erforderlicher Executors wird anhand der Anzahl der aktiven und ausstehenden Aufgaben berechnet, sie könnte also kleiner sein als die Anzahl der aktiven Executors. Dies liegt daran, dass es Executors geben kann, die für einen kurzen Zeitraum teilweise oder vollständig im Leerlauf sind und noch nicht außer Betrieb genommen wurden.
![\[Graph, der die Gesamtzahl aktiver Executors zeigt, die die maximal zugewiesene Anzahl erreicht.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-4.png)
Dieser Auftrag nutzt sechsmal mehr Executors für parallele Lese- und Schreibvorgänge in Amazon S3. Dies hat zur Folge, dass diese Auftragsausführung mehr Amazon-S3-Bandbreite für Lese- und Schreibvorgänge verwendet und schneller fertiggestellt wird.
### Identifizieren Sie übermäßig bereitgestellte DPUs
Als Nächstes können Sie feststellen, ob eine weitere Skalierung des Jobs mit 100 DPUs (99 \$1 2 = 198 Executoren) hilfreich ist. Wie der folgende Graph zeigt, dauert die Fertigstellung des Auftrags immer noch drei Minuten. Ebenso kann der Job nicht über 107 Executoren ( DPUsKonfiguration 55) hinaus skaliert werden, und die verbleibenden 91 Executoren sind überprovisioniert und werden überhaupt nicht verwendet. Dies zeigt, dass eine Erhöhung der Anzahl von Executoren DPUs möglicherweise nicht immer zu einer Verbesserung der Leistung führt, wie anhand der maximal benötigten Anzahl von Executoren deutlich wird.
![\[Aus der Grafik geht hervor, dass die Arbeitsleistung nicht immer steigt, wenn die Anzahl der DPUs\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-5.png)
### Vergleich von Zeitunterschieden
Die drei in der folgenden Tabelle aufgeführten Auftragsausführungen fassen die Ausführungszeiten für 10 DPUs DPUs, 55 und 100 DPUs Jobs zusammen. Sie finden die DPU-Kapazität zur Verbesserung der Auftragsausführungszeit unter Verwendung der Schätzungen, die Sie bei der Überwachung der ersten Auftragsausführung eingerichtet haben.
| Auftrags-ID | Anzahl der DPUs | Execution time (Ausführungszeit) |
| --- | --- | --- |
| jr\$1c894524c8ef5048a4d9... | 10 | 6 Minuten |
| jr\$11a466cf2575e7ffe6856... | 55 | 3 Minuten |
| jr\$134fa1ed4c6aa9ff0a814... | 100 | 3 Minuten |