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.
Grundlegendes zum Anwendungsverhalten in EMR Serverless
In diesem Abschnitt werden das Verhalten bei der Auftragsübermittlung, die Kapazitätskonfiguration für die Skalierung und die Worker-Konfigurationseinstellungen für EMR Serverless beschrieben.
Standardverhalten von Anwendungen
Auto-start— Eine Anwendung ist standardmäßig so konfiguriert, dass sie bei der Einreichung eines Jobs automatisch gestartet wird. Sie können diese Funktion ausschalten.
Auto-stop— Eine Anwendung ist standardmäßig so konfiguriert, dass sie automatisch stoppt, wenn sie 15 Minuten lang inaktiv ist. Wenn eine Anwendung in den STOPPED Status wechselt, gibt sie alle konfigurierten vorinitialisierten Kapazitäten frei. Sie können die Dauer der Leerlaufzeit ändern, bevor eine Anwendung automatisch beendet wird, oder Sie können diese Funktion deaktivieren.
Maximale Kapazität
Sie können die maximale Kapazität konfigurieren, auf die eine Anwendung skaliert werden kann. Sie können Ihre maximale Kapazität in Bezug auf CPU, Arbeitsspeicher (GB) und Festplatte (GB) angeben.
Anmerkung
Es empfiehlt sich, Ihre maximale Kapazität so zu konfigurieren, dass sie proportional zu Ihrer unterstützten Mitarbeitergröße ist, indem Sie die Anzahl der Mitarbeiter mit ihrer Größe multiplizieren. Wenn Sie Ihre Anwendung beispielsweise auf 50 Worker mit 2 vCPUs, 16 GB Arbeitsspeicher und 20 GB Festplatte beschränken möchten, legen Sie Ihre maximale Kapazität auf 100 vCPUs, 800 GB für Arbeitsspeicher und 1000 GB für Festplatte fest.
Unterstützte Worker-Konfigurationen
In der folgenden Tabelle sind die unterstützten Worker-Konfigurationen und -Größen aufgeführt, die für EMR Serverless angegeben werden können. Konfigurieren Sie je nach den Anforderungen Ihrer Arbeitslast unterschiedliche Größen für Treiber und Executoren.
| CPU | Arbeitsspeicher | Temporärer Standardspeicher |
|---|---|---|
|
1 vCPU |
Mindestens 2 GB, maximal 8 GB, in Schritten von 1 GB |
20 GB — 200 GB |
|
2 vCPU |
Mindestens 4 GB, maximal 16 GB, in Schritten von 1 GB |
20 GB — 200 GB |
|
4 vCPU |
Mindestens 8 GB, maximal 30 GB, in Schritten von 1 GB |
20 GB — 200 GB |
|
8 vCPU |
Mindestens 16 GB, maximal 60 GB, in Schritten von 4 GB |
20 GB — 200 GB |
|
16 vCPU |
Mindestens 32 GB, maximal 120 GB, in Schritten von 8 GB |
20 GB — 200 GB |
|
32 vCPU |
Drei diskrete Werte: 60 GB, 120 GB oder 244 GB |
20 GB — 200 GB |
CPU — Jeder Worker kann über 1, 2, 4, 8, 16 oder 32 vCPUs verfügen.
Arbeitsspeicher — Jeder Worker verfügt über Arbeitsspeicher, der in GB angegeben wird und innerhalb der in der obigen Tabelle aufgeführten Grenzwerte liegt. Spark-Jobs haben einen Speicheraufwand, was bedeutet, dass der Speicherplatz, den sie verwenden, die angegebenen Containergrößen übersteigt. Dieser Overhead wird mit den Eigenschaften spark.driver.memoryOverhead und angegebenspark.executor.memoryOverhead. Der Overhead hat einen Standardwert von 10% des Container-Speichers mit einem Minimum von 384 MB. Sie sollten diesen Mehraufwand berücksichtigen, wenn Sie die Größe der Mitarbeiter wählen.
Wenn Sie beispielsweise 4 vCPUs für Ihre Worker-Instance und eine vorinitialisierte Speicherkapazität von 30 GB wählen, legen Sie einen Wert von etwa 27 GB als Executor-Speicher für Ihren Spark-Job fest. Dadurch wird die Nutzung Ihrer vorinitialisierten Kapazität maximiert. Der nutzbare Arbeitsspeicher beträgt 27 GB plus 10% von 27 GB (2,7 GB), also insgesamt 29,7 GB.
Für Worker mit 32 vCPUs muss der Arbeitsspeicher einer von drei diskreten Konfigurationen entsprechen: 60 GB, 120 GB oder 244 GB. EMR Serverless validiert die gesamte Speicheranforderung (Spark-konfigurierter Speicher plus Speicher-Overhead) und lehnt Jobs ab, deren Summe nicht zu einer der drei Konfigurationen passt. spark.executor.memoryzusammen mit dem Speicher-Overhead (standardmäßig 10%) muss der Wert innerhalb von 8 GB der unterstützten Arbeitsspeicherkonfiguration liegen. Beispiel: Ein Spark-Job, der einen 32-vCPU-Worker mit einer spark.executor.memory Einstellung von 100 GB anfordert, wird abgelehnt, weil die Summe von 110 GB (nach dem Hinzufügen des standardmäßigen Overheads von 10%) nicht innerhalb von 8 GB der unterstützten Worker-Größe von 120 GB liegt. In diesem Fall werden spark.executor.memory Werte im Bereich von 102 GB bis 109 GB akzeptiert.
Festplatte — Sie können jeden Worker mit temporären Speicherfestplatten mit einer Mindestgröße von 20 GB und einer Höchstgröße von 200 GB konfigurieren. Sie zahlen nur für zusätzlichen Speicherplatz über 20 GB, den Sie pro Mitarbeiter konfigurieren.
