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. # Fehlerbehebung bei einem langsamen Amazon EMR-Cluster In diesem Abschnitt wird die Fehlerbehebung eines Clusters beschrieben, der noch ausgeführt wird, aber viel Zeit benötigt, um Ergebnisse zurückzugeben. Weitere Informationen zu Verfahren, die Sie anwenden können, wenn der Cluster mit einem Fehlercode beendet wurde, finden Sie unter [Fehlerbehebung bei einem Amazon EMR-Cluster, der mit einem Fehlercode ausgefallen ist](emr-troubleshoot-failed.md) Mit Amazon EMR können Sie die Anzahl und Art der Instances im Cluster festlegen. Diese Spezifikationen sind die beste Möglichkeit, die Geschwindigkeit, mit der Ihre Daten verarbeitet werden, zu beeinflussen. Sie können eine erneute Ausführung des Clusters in Betracht ziehen. Hierbei legen Sie EC2-Instances mit mehr Ressourcen oder eine größere Anzahl der Instances im Cluster fest. Weitere Informationen finden Sie unter [Amazon EMR-Cluster-Hardware und -Netzwerke konfigurieren](emr-plan-instances.md). In den folgenden Themen wird erklärt, wie Sie alternative Ursachen für einen langsamen Cluster identifizieren. **Topics** + [Schritt 1: Sammeln Sie Daten über das Problem mit dem Amazon EMR-Cluster](emr-troubleshoot-slow-1.md) + [Schritt 2: Überprüfen Sie die EMR-Cluster-Umgebung](emr-troubleshoot-slow-2.md) + [Schritt 3: Untersuchen Sie die Protokolldateien für den Amazon EMR-Cluster](emr-troubleshoot-slow-3.md) + [Schritt 4: Überprüfen Sie den Zustand des Amazon EMR-Clusters und der Instance](emr-troubleshoot-slow-4.md) + [Schritt 5: Nach gesperrten Gruppen suchen](emr-troubleshoot-slow-5.md) + [Schritt 6: Überprüfen Sie die Konfigurationseinstellungen für den Amazon EMR-Cluster](emr-troubleshoot-slow-6.md) + [Schritt 7: Untersuchen Sie die Eingabedaten für den Amazon EMR-Cluster](emr-troubleshoot-slow-7.md) # Schritt 1: Sammeln Sie Daten über das Problem mit dem Amazon EMR-Cluster Der erste Schritt bei der Fehlerbehebung bei einem Cluster besteht darin, Informationen darüber zu sammeln, was schief gelaufen ist, sowie über den aktuellen Status und die Konfiguration des Clusters. Diese Informationen werden in den folgenden Schritten verwendet, um mögliche Ursachen des Problems zu bestätigen oder auszuschließen. ## Definieren des Problems Eine klare Definition des Problems ist der erste Ausgangspunkt. Einige Fragen, die Sie sich stellen sollten: + Was habe ich erwartet? Was ist stattdessen passiert? + Wann ist dieses Problem zum ersten Mal aufgetreten? Wie oft ist es seitdem passiert? + Hat sich etwas an der Konfiguration oder Ausführung meines Clusters geändert? ## Cluster-Details Die folgenden Clusterdetails sind hilfreich, um Probleme aufzuspüren. Weitere Informationen zum Sammeln dieser Informationen finden Sie unter [Status und Details des Amazon EMR-Clusters anzeigen](emr-manage-view-clusters.md). + Die Cluster-ID. (Wird auch als Job-Flow-Identifier bezeichnet.) + AWS-Region und Availability Zone, in der der Cluster gestartet wurde. + Status des Clusters, einschließlich Details zur letzten Statusänderung. + Typ und Anzahl der EC2-Instances, die für die Master-, Core- und Aufgabenknoten angegeben wurden. # Schritt 2: Überprüfen Sie die EMR-Cluster-Umgebung Prüfen Sie in Ihrer Umgebung, ob es Serviceausfälle gibt oder ob Sie ein AWS Servicelimit überschritten haben. **Topics** + [Prüfen auf Service-Ausfälle](#emr-troubleshoot-slow-2-outages) + [Prüfen auf Nutzungsgrenzen](#emr-troubleshoot-slow-2-limits) + [Prüfen der Amazon-VPC-Subnetzkonfiguration](#emr-troubleshoot-slow-2-vpc) + [Neustarten des Clusters](#emr-troubleshoot-slow-2-restart) ## Prüfen auf Service-Ausfälle Amazon EMR verwendet intern mehrere Amazon Web Services. Es betreibt virtuelle Server auf Amazon EC2, speichert Daten und Skripts auf Amazon S3 und meldet Metriken an CloudWatch. Ereignisse, die diese Services stören, sind selten – wenn sie jedoch auftreten, können sie zu Problemen in Amazon EMR führen. Überprüfen Sie die [Übersicht zum Servicestatus](https://status.aws.amazon.com/), bevor Sie fortfahren. Prüfen Sie in der Region, in der Sie Ihren Cluster gestartet haben, ob es bei einem dieser Services zu Störungen gekommen ist. ## Prüfen auf Nutzungsgrenzen Wenn Sie einen großen Cluster starten, viele Cluster gleichzeitig gestartet haben oder wenn Sie ein Benutzer sind, der sich einen Cluster AWS-Konto mit anderen Benutzern teilt, ist der Cluster möglicherweise ausgefallen, weil Sie ein AWS Service-Limit überschritten haben. Amazon EC2 begrenzt die Anzahl der virtuellen Server-Instances, die in einer einzelnen AWS Region ausgeführt werden, auf 20 On-Demand-Instances oder Reserved Instances. Wenn Sie einen Cluster mit mehr als 20 Knoten starten oder einen Cluster starten, der dazu führt, dass die Gesamtzahl der auf Ihrem AWS-Konto Computer aktiven EC2-Instances 20 überschreitet, kann der Cluster nicht alle benötigten EC2-Instances starten und kann ausfallen. In diesem Fall gibt Amazon EMR einen `EC2 QUOTA EXCEEDED`-Fehler zurück. Sie können eine AWS Erhöhung der Anzahl der EC2-Instances, die Sie auf Ihrem Konto ausführen können, beantragen, indem Sie einen [Antrag auf Erhöhung des Amazon EC2 EC2-Instance-Limits](https://aws.amazon.com/contact-us/ec2-request/) einreichen. Eine weitere Sache, die dazu führen kann, dass Sie Ihre Nutzungslimits überschreiten, ist die Verzögerung zwischen der Beendigung eines Clusters und der Freigabe aller seiner Ressourcen. Je nach Konfiguration kann es bis zu 5–20 Minuten dauern, bis ein Cluster vollständig beendet ist und zugewiesene Ressourcen freigibt. Wenn Sie beim Versuch, einen Custer zu starten, die Fehlermeldung `EC2 QUOTA EXCEEDED` erhalten, kann es daran liegen, dass Ressourcen eines kürzlich beendeten Clusters noch nicht zur Verfügung stehen. In diesem Fall können Sie entweder [eine Erhöhung Ihres Amazon-EC2-Kontingents](https://aws.amazon.com/contact-us/ec2-request/) beantragen oder zwanzig Minuten warten und den Cluster neu starten. Amazon S3 begrenzt die Anzahl der auf einem Konto erstellten Buckets auf 100. Wenn Ihr Cluster einen neuen Bucket erstellt, der dieses Limit überschreitet, schlägt die Bucket-Erstellung fehl und kann dazu führen, dass der Cluster fehlschlägt. ## Prüfen der Amazon-VPC-Subnetzkonfiguration Wenn Ihr Cluster in einem Amazon VPC-Subnetz gestartet wurde, muss das Subnetz wie unter [Konfiguration von Netzwerken in einer VPC für Amazon EMR](emr-plan-vpc-subnet.md) beschrieben konfiguriert werden. Überprüfen Sie außerdem, ob das Subnetz, in dem Sie den Cluster starten, über genügend freie elastische IP-Adressen verfügt, um jedem Knoten im Cluster eine zuzuweisen. ## Neustarten des Clusters Die Verlangsamung der Verarbeitung kann von einer vorübergehenden Bedingung herrühren. Überlegen Sie sich, ob Sie den Cluster beenden und neu starten möchten, um zu prüfen, ob sich die Leistung verbessert. # Schritt 3: Untersuchen Sie die Protokolldateien für den Amazon EMR-Cluster Der nächste Schritt besteht darin, die Protokolldateien zu untersuchen, um einen Fehlercode oder einen anderen Hinweis auf das Problem zu finden, das in Ihrem Cluster aufgetreten ist. Informationen zu den verfügbaren Protokolldateien, wo sie zu finden sind und wie Sie sie anzeigen können, finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md). Es kann einige Nachforschungen erfordern, um herauszufinden, was passiert ist. Hadoop führt die Arbeit der Aufträge in Aufgabenversuchen auf verschiedenen Knoten im Cluster aus. Amazon EMR kann spekulative Aufgabenversuche initiieren und die anderen Aufgabenversuche beenden, die nicht zuerst abgeschlossen werden. Dadurch werden umfangreiche Aktivitäten generiert, die in den Controller-, Stderr- und Syslog-Protokolldateien protokolliert werden. Darüber hinaus werden mehrere Aufgaben gleichzeitig ausgeführt, aber eine Protokolldatei kann die Ergebnisse nur linear anzeigen. Überprüfen Sie zunächst die Bootstrap-Aktionsprotokolle auf Fehler oder unerwartete Konfigurationsänderungen beim Start des Clusters. Suchen Sie anschließend in den Schrittprotokollen nach Hadoop-Aufträgen, die als Teil eines fehlerhaften Schritts gestartet wurden. Untersuchen Sie die Hadoop-Auftragsprotokolle, um die fehlgeschlagenen Aufgabenversuche zu identifizieren. Das Protokoll der Aufgabenversuche wird Details darüber enthalten, was zum Fehlschlagen eines Aufgabenversuchs geführt hat. In den folgenden Abschnitten wird erläutert, wie die verschiedenen Protokolldateien verwendet werden, um Fehler in Ihrem Cluster zu identifizieren. ## Die Bootstrap-Aktionsprotokolle überprüfen Bootstrap-Aktionen führen Skripts auf dem Cluster aus, während dieser gestartet wird. Sie werden häufig verwendet, um zusätzliche Software auf dem Cluster zu installieren oder um Konfigurationseinstellungen gegenüber den Standardwerten zu ändern. Die Überprüfung dieser Protokolle kann Aufschluss über Fehler geben, die bei der Einrichtung des Clusters aufgetreten sind, sowie über Änderungen der Konfigurationseinstellungen, die sich auf die Leistung auswirken könnten. ## Die Schrittprotokolle überprüfen Es gibt vier Arten von Schrittprotokollen. + **Controller – ** Enthält von Amazon EMR (Amazon EMR) generierte Dateien, die auf Fehler zurückzuführen sind, die bei der Ausführung Ihres Schritts aufgetreten sind. Wenn Ihr Schritt beim Laden fehlschlägt, finden Sie den Stack-Trace in diesem Protokoll. Fehler beim Laden oder Zugreifen auf Ihre Anwendung werden hier häufig beschrieben, ebenso wie Fehler in der fehlenden Mapper-Datei. + **stderr – ** Enthält Fehlermeldungen, die bei der Verarbeitung des Schritts aufgetreten sind. Fehler beim Laden von Anwendungen werden hier häufig beschrieben. Dieses Protokoll enthält manchmal einen Stack-Trace. + **stdout – ** Enthält den Status, der von Ihren ausführbaren Mapper- und Reducer-Dateien generiert wurde. Fehler beim Laden von Anwendungen werden hier häufig beschrieben. Dieses Protokoll enthält manchmal Anwendungsfehlermeldungen. + **syslog – ** Enthält Protokolle von Software, die nicht von Amazon stammt, wie Apache und Hadoop. Streaming-Fehler werden hier häufig beschrieben. Überprüfen Sie stderr auf offensichtliche Fehler. Wenn stderr eine kurze Liste von Fehlern anzeigt, wurde der Schritt schnell beendet und es wurde ein Fehler ausgelöst. Dies wird meistens durch einen Fehler in den Mapper- und Reducer-Anwendungen verursacht, die im Cluster ausgeführt werden. Untersuchen Sie die letzten Zeilen von Controller und Syslog auf Hinweise auf Fehler oder Ausfälle. Folgen Sie allen Hinweisen zu fehlgeschlagenen Aufgaben, insbesondere wenn dort „Auftrag fehlgeschlagen“ steht. ## Die Aufgabenversuchsprotokolle überprüfen Wenn die vorherige Analyse der Schrittprotokolle eine oder mehrere fehlgeschlagene Aufgaben ergeben hat, suchen Sie in den Protokollen der entsprechenden Aufgabenversuche nach detaillierteren Fehlerinformationen. ## Die Hadoop-Daemon-Protokolle überprüfen In seltenen Fällen kann Hadoop selbst ausfallen. Um zu sehen, ob das der Fall ist, müssen Sie sich die Hadoop-Protokolle ansehen. Sie befinden sich auf `/var/log/hadoop/` auf jedem Knoten. Sie können die JobTracker Protokolle verwenden, um einen fehlgeschlagenen Taskversuch dem Knoten zuzuordnen, auf dem er ausgeführt wurde. Sobald Sie den Knoten kennen, der mit dem Aufgabenversuch verknüpft ist, können Sie den Zustand der EC2-Instance überprüfen, die diesen Knoten hostet, um festzustellen, ob Probleme wie etwa ein Mangel an CPU oder Arbeitsspeicher aufgetreten sind. # Schritt 4: Überprüfen Sie den Zustand des Amazon EMR-Clusters und der Instance Ein Amazon-EMR-Cluster besteht aus Knoten, die auf Amazon EC2 Instances ausgeführt werden. Wenn diese Instances viele Ressourcen binden (z. B. CPU oder Speicherplatz), Probleme mit der Netzwerkkonnektivität haben oder beendet werden, leidet die Geschwindigkeit der Cluster-Verarbeitung. Es gibt bis zu drei Arten von Knoten in einem Cluster: + **Hauptknoten** – verwaltet den Cluster. Wenn ein Leistungsproblem auftritt, ist der gesamte Cluster betroffen. + **Core-Knoten** – verarbeiten Map- und Reduce-Aufgaben und verwalten das Hadoop Distributed File System (HDFS). Wenn einer dieser Knoten ein Leistungsproblem hat, kann dies sowohl HDFS-Operationen als auch Map- und Reduce-Verarbeitungen verlangsamen. Sie können einem Cluster zusätzliche Core-Knoten hinzufügen, um die Leistung zu verbessern, aber keine Core-Knoten entfernen. Weitere Informationen finden Sie unter [Manuelles Ändern der Größe eines laufenden Amazon EMR-Clusters](emr-manage-resize.md). + **Aufgabenknoten** – verarbeiten Map- und Reduce-Aufgaben. Dies sind reine Rechenressourcen und speichern keine Daten. Sie können einem Cluster Aufgabenknoten hinzufügen, um die Leistung zu beschleunigen, oder nicht benötigte Aufgabenknoten entfernen. Weitere Informationen finden Sie unter [Manuelles Ändern der Größe eines laufenden Amazon EMR-Clusters](emr-manage-resize.md). Wenn Sie den Zustand eines Clusters prüfen, sollten Sie sich sowohl die Leistung des Clusters insgesamt als auch die Leistung der einzelnen Instances anschauen. Es gibt mehrere Tools, die Sie verwenden können: ## Überprüfen Sie den Zustand des Clusters mit CloudWatch Jeder Amazon EMR-Cluster meldet Metriken an CloudWatch. Diese Metriken stellen zusammenfassende Leistungsinformationen über den Cluster bereit, wie z. B. Gesamtlast, HDFS-Auslastung, ausgeführte Aufgaben, verbleibende Aufgaben und beschädigte Blöcke. Wenn Sie sich die CloudWatch Metriken ansehen, erhalten Sie einen Überblick darüber, was in Ihrem Cluster vor sich geht, und Sie erhalten einen Einblick in die Ursachen für die Verlangsamung der Verarbeitung. Sie können nicht nur ein vorhandenes Leistungsproblem analysieren, sondern auch Alarme einrichten, die eine Warnung auslösen CloudWatch , wenn ein future Leistungsproblem auftritt. CloudWatch Weitere Informationen finden Sie unter [Überwachung von Amazon EMR-Metriken mit CloudWatch](UsingEMR_ViewingMetrics.md). ## Überprüfen von Auftragsstatus und HDFS-Zustand Verwenden Sie die Option **Application user interface (Anwendungsbenutzeroberflächen)** auf der Detailseite des Clusters, um Details zur YARN-Anwendung anzuzeigen. Bei bestimmten Anwendungen können Sie weitere Details und Zugriffsprotokolle direkt anzeigen. Dies ist besonders nützlich für Spark-Anwendungen. Weitere Informationen finden Sie unter [Amazon EMR-Anwendungsverlauf anzeigen](emr-cluster-application-history.md). Hadoop bietet eine Reihe von Webschnittstellen, mit denen Sie Informationen anzeigen lassen können. Weitere Informationen darüber, wie Sie auf diese Webschnittstellen zugreifen können, finden Sie unter [Anzeigen von auf Amazon-EMR-Clustern gehosteten Webschnittstellen](emr-web-interfaces.md). + JobTracker — liefert Informationen über den Status des Jobs, der vom Cluster verarbeitet wird. Mit dieser Schnittstelle können Sie ermitteln, wann ein Auftrag blockiert ist. + HDFS NameNode — liefert Informationen über den Prozentsatz der HDFS-Auslastung und den verfügbaren Speicherplatz auf jedem Knoten. Sie können mit dieser Schnittstelle bestimmen, wann HDFS Ressourcen bindet und zusätzliche Kapazität benötigt. + TaskTracker — liefert Informationen über die Aufgaben des Jobs, die vom Cluster verarbeitet werden. Mit dieser Schnittstelle können Sie ermitteln, wann eine Aufgabe blockiert ist. ## Instance-Zustandsprüfung mit Amazon EC2 Die Amazon-EC2-Konsole bietet eine weitere Möglichkeit, um Informationen über den Status der Instances in Ihrem Cluster zu ermitteln. Da jeder Knoten im Cluster auf einer EC2-Instance ausgeführt wird, können Sie mithilfe der von Amazon EC2 bereitgestellten Tools ihren Status überprüfen. Weitere Informationen finden Sie unter [Anzeigen von Cluster-Instances in Amazon EC2](UsingEMR_Tagging.md). # Schritt 5: Nach gesperrten Gruppen suchen Eine Instance-Truppe wird angehalten, wenn beim Versuch, einen Knoten zu starten, zu viele Fehler auftreten. Wenn z. B. neue Knoten während der Durchführung von Bootstrap-Aktionen wiederholt fehlschlagen, wechselt die Instance-Gruppe nach einiger Zeit in den Status `SUSPENDED`, anstatt fortlaufend zu versuchen, neue Knoten bereitzustellen. In folgenden Fällen kann ein Knoten fehlschlagen: + Hadoop oder der Cluster ist irgendwie beschädigt und akzeptiert keinen neuen Knoten im Cluster. + Eine Bootstrap-Aktion schlägt auf dem neuen Knoten fehl. + Der Knoten arbeitet nicht ordnungsgemäß und kann nicht mit Hadoop einchecken Wenn sich eine Instance-Gruppe im Status `SUSPENDED` befindet und der Cluster den Status `WAITING` hat, können Sie einen Cluster-Schritt hinzufügen, um die gewünschte Anzahl von Core- und Aufgabenknoten zurückzusetzen. Durch Hinzufügen des Schritts wird die Verarbeitung des Clusters fortgesetzt und die Instance-Gruppe wieder in den Status `RUNNING` versetzt. Weitere Informationen zum Zurücksetzen eines Clusters im angehaltenen Zustand finden Sie unter [Suspendierter Zustand](emr-manage-resize.md#emr-manage-resizeSuspended). # Schritt 6: Überprüfen Sie die Konfigurationseinstellungen für den Amazon EMR-Cluster Konfigurationseinstellungen legen die Ausführung eines Clusters im Detail fest, z. B. wie häufig eine Aufgabe wiederholt wird und wie viel Arbeitsspeicher zum Sortieren verfügbar ist. Wenn Sie einen Cluster mithilfe von Amazon EMR starten, gibt es zusätzlich zu den standardmäßigen Hadoop-Konfigurationseinstellungen auch Amazon-EMR-spezifische Einstellungen. Die Konfigurationseinstellungen werden im Master-Knoten des Clusters gespeichert. Sie können die Konfigurationseinstellungen überprüfen, um sicherzustellen, dass Ihr Cluster über die benötigten Ressourcen für einen effizienten Betrieb verfügt. Amazon EMR legt standardmäßige Hadoop-Konfigurationseinstellungen fest, die zum Starten eines Clusters verwendet werden. Die Werte basieren auf dem AMI und dem Instance-Typ, den Sie für den Cluster angeben. Ändern können Sie die Standardwerte der Konfigurationseinstellungen mithilfe einer Bootstrap-Aktion oder indem Sie neue Wert in den Parametern für die Auftragsausführung festlegen. Weitere Informationen finden Sie unter [Erstellen Sie Bootstrap-Aktionen, um zusätzliche Software mit einem Amazon EMR-Cluster zu installieren](emr-plan-bootstrap.md). Um zu bestimmen, ob eine Bootstrap-Aktion die Konfigurationseinstellungen geändert hat, prüfen Sie die Bootstrap-Aktionsprotokolle. Amazon EMR protokolliert die Hadoop-Einstellungen für die Ausführung aller Aufträge. Die Protokolldaten werden in einer Datei gespeichert, die `job_job-id_conf.xml` unter dem `/mnt/var/log/hadoop/history/` Verzeichnis des Master-Knotens benannt *job-id* ist und dort durch die ID des Auftrags ersetzt wird. Wenn Sie die Protokollarchivierung aktiviert haben, werden diese Daten in dem `logs/date/jobflow-id/jobs` Ordner nach Amazon S3 kopiert, wo sich das Datum *date* befindet, an dem der Job ausgeführt wurde, und der Identifier des Clusters *jobflow-id* ist. Die folgenden Konfigurationseinstellungen des Hadoop-Auftrags eignen sich besonders für die Untersuchung von Leistungsproblemen. Weitere Informationen zu den Hadoop-Konfigurationseinstellungen und deren Auswirkungen auf das Verhalten von Hadoop finden Sie unter [http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/). **Warnung** Das Festlegen von `dfs.replication` auf 1 auf Clustern mit weniger als vier Knoten kann zu einem HDFS-Datenverlust führen, wenn ein einzelner Knoten ausfällt. Wir empfehlen, für Produktionsworkloads einen Cluster mit mindestens vier Core-Knoten zu verwenden. Amazon EMR erlaubt Clustern nicht, Core-Knoten unter `dfs.replication` zu skalieren. Bei `dfs.replication = 2` z. B. beträgt die Mindestanzahl von Core-Knoten 2. Wenn Sie verwaltete Skalierung oder Auto-Scaling verwenden oder die Größe Ihres Clusters manuell ändern möchten, empfehlen wir Ihnen, `dfs.replication` auf 2 oder höher einzustellen. | Konfigurationseinstellung | Description | | --- | --- | | dfs.replication | Die Anzahl der HDFS-Knoten, in die ein einziger Block (z. B. der Festplattenblock) kopiert wird, um eine RAID-ähnliche Umgebung zu erstellen. Bestimmt die Anzahl der HDFS-Knoten, die eine Kopie des Blocks enthalten. | | io.sort.mb | Für die Sortierung verfügbarer Gesamtspeicher. Dieser Wert sollte das Zehnfache von "io.sort.factor" sein. Diese Einstellung kann auch für die Berechnung des vom Aufgabenknoten genutzten Gesamtspeichers durch Berechnen von "io.sort.mb" multipliziert mit "mapred.tasktracker.ap.tasks.maximum" verwendet werden. | | io.sort.spill.percent | Wird während der Sortierung verwendet. An diesem Punkt beginnt die Verwendung des Datenträgers, da der für die Sortierung zugewiesene Speicherplatz knapp wird. | | mapred.child.java.opts | Als veraltet gekennzeichnet. Verwenden Sie stattdessen "mapred.map.child.java.opts" und "mapred.reduce.child.java.opts". Die Java-Optionen, die TaskTracker verwendet werden, wenn eine JVM gestartet wird, damit eine Aufgabe darin ausgeführt wird. "-Xmx" ist ein üblicher Parameter zum Festlegen der maximalen Arbeitsspeichergröße. | | mapred.map.child.java.opts | Die Java-Optionen, die beim Starten einer JVM für eine Map-Aufgabe TaskTracker verwendet werden, die darin ausgeführt werden soll. "-Xmx" ist ein üblicher Parameter zum Festlegen der maximalen Heap-Arbeitsspeichergröße. | | mapred.map.tasks.speculative.execution | Legt fest, ob Map-Aufgabenversuche derselben Aufgabe parallel gestartet werden können. | | mapred.reduce.tasks.speculative.execution | Legt fest, ob Reduce-Aufgabenversuche derselben Aufgabe parallel gestartet werden können. | | mapred.map.max.attempts | Die maximale Anzahl an Map-Aufgabenversuchen. Wenn alle fehlschlagen, wird die Map-Aufgabe als fehlgeschlagen markiert. | | mapred.reduce.child.java.opts | Die Java-Optionen, die beim Starten einer JVM für eine Reduce-Aufgabe zur Ausführung innerhalb einer JVM TaskTracker verwendet werden. "-Xmx" ist ein üblicher Parameter zum Festlegen der maximalen Heap-Arbeitsspeichergröße. | | mapred.reduce.max.attempts | Die maximale Anzahl an Reduce-Aufgabenversuchen. Wenn alle fehlschlagen, wird die Map-Aufgabe als fehlgeschlagen markiert. | | mapred.reduce.slowstart.completed.maps | Die Anzahl an Map-Aufgaben, die abgeschlossen werden, bevor Reduce-Aufgabenversuche durchgeführt werden. Bei zu geringer Wartezeit kann der Fehler „Too many fetch" in Versuchen ausgelöst werden. | | mapred.reuse.jvm.num.tasks | Eine Aufgabe wird innerhalb einer einzelnen JVM ausgeführt. Gibt an, wie viele Aufgaben dieselbe JVM wiederverwenden dürfen. | | mapred.tasktracker.map.tasks.maximum | Die maximale Anzahl von Aufgaben, die während des Map-Vorgangs pro Aufgabenknoten parallel ausgeführt werden können. | | mapred.tasktracker.reduce.tasks.maximum | Die maximale Anzahl von Aufgaben, die während des Reduce-Vorgangs pro Aufgabenknoten parallel ausgeführt werden können. | Wenn Ihre Cluster-Aufgaben arbeitsspeicherintensiv sind, können Sie die Leistung verbessern, indem Sie weniger Aufgaben pro Core-Knoten verwenden und die Heap-Größe des JobTrackers reduzieren. # Schritt 7: Untersuchen Sie die Eingabedaten für den Amazon EMR-Cluster Schauen Sie sich Ihre Eingabedaten an. Sind diese gleichmäßig auf Ihre Schlüsselwerte verteilt? Bei einer starken Datenschiefe in Richtung eines oder weniger Schlüsselwerte wird die Verarbeitungslast möglicherweise einer kleinen Anzahl von Knoten zugeordnet, während sich andere Knoten im Leerlauf befinden. Diese ungleichmäßige Verteilung der Arbeit kann zu einer langsameren Verarbeitung führen. Um einen ungleichmäßigen Datensatz handelt es sich z. B., wenn ein Cluster ausgeführt wird, um Wörter alphabetisch anzuordnen, aber ein Datensatz zur Verfügung steht, dessen Wörter alle nur mit "a" beginnen. Beim Map-Vorgang wird dann der Knoten überfordert, der Werte verarbeitet, die mit "a" anfangen, während diejenigen Knoten nicht beschäftigt sind, die Wörter mit anderen Anfangsbuchstaben verarbeiten.