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 Verhalten von Anwendungen
Standardverhalten der Anwendung
Autostart — Eine Anwendung ist standardmäßig so konfiguriert, dass sie bei der Auftragserteilung 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 Arbeitsspeicher (GB) und Festplatte (GB) angeben. CPU
Anmerkung
Wir empfehlen, 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 Mitarbeiter mit 2vCPUs, 16 GB Arbeitsspeicher und 20 GB Festplatte beschränken möchten, legen Sie Ihre maximale Kapazität auf 100vCPUs, 800 GB für Arbeitsspeicher und 1000 GB für Festplatte fest.
Unterstützte Worker-Konfigurationen
Die folgende Tabelle zeigt die unterstützten Worker-Konfigurationen und -Größen, die Sie für EMR Serverless angeben können. Sie können je nach den Anforderungen Ihrer Arbeitslast unterschiedliche Größen für Treiber und Executoren konfigurieren.
| CPU | Arbeitsspeicher | Temporärer Standardspeicher |
|---|---|---|
|
1 v CPU |
Mindestens 2 GB, maximal 8 GB, in Schritten von 1 GB |
20 GB — 200 GB |
|
2 v CPU |
Mindestens 4 GB, maximal 16 GB, in Schritten von 1 GB |
20 GB — 200 GB |
|
4 v CPU |
Mindestens 8 GB, maximal 30 GB, in Schritten von 1 GB |
20 GB — 200 GB |
|
8 V CPU |
Mindestens 16 GB, maximal 60 GB, in Schritten von 4 GB |
20 GB — 200 GB |
|
16 v CPU |
Mindestens 32 GB, maximal 120 GB, in Schritten von 8 GB |
20 GB — 200 GB |
CPU— Jeder Arbeiter kann 1, 2, 4, 8 oder 16 habenvCPUs.
Arbeitsspeicher — Jeder Worker verfügt über Arbeitsspeicher, der in GB angegeben wird und innerhalb der in der vorherigen 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, sollten Sie einen Wert von etwa 27 GB als Executor-Speicher für Ihren Spark-Job festlegen. Dadurch wird die Nutzung Ihrer vorinitialisierten Kapazität maximiert. Der nutzbare Arbeitsspeicher wäre 27 GB plus 10% von 27 GB (2,7 GB), also insgesamt 29,7 GB.
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.
