Amazon Elastic MapReduce - SIGTERM

Ich habe einen EMR-Streaming-Job (Python), der normalerweise gut funktioniert (z. B. 10 Maschinen, die 200 Eingaben verarbeiten). Allerdings, wenn ich laufen sie gegen große Datenmengen (12 Maschinen Verarbeitung insgesamt 6000 Eingänge, bei etwa 20 Sekunden pro Eingang), nach 2,5 Stunden von Knirschen ich folgende Fehlermeldung erhalten:Amazon Elastic MapReduce - SIGTERM

java.lang.RuntimeException: PipeMapRed.waitOutputThreads(): subprocess failed with code 143 
at org.apache.hadoop.streaming.PipeMapRed.waitOutputThreads(PipeMapRed.java:372) 
at org.apache.hadoop.streaming.PipeMapRed.mapRedFinished(PipeMapRed.java:586) 
at org.apache.hadoop.streaming.PipeMapper.close(PipeMapper.java:135) 
at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:57) 
at org.apache.hadoop.streaming.PipeMapRunner.run(PipeMapRunner.java:36) 
at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:441) 
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:377) 
at org.apache.hadoop.mapred.Child$4.run(Child.java:255) 
at java.security.AccessController.doPrivileged(Native Method) 
at javax.security.auth.Subject.doAs(Subject.java:396) 
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1132) 
at org.apache.hadoop.mapred.Child.main(Child.java:249)

Wenn ich das Lesen bin Dies richtig, der Subprozess ist mit Code 143 fehlgeschlagen, da jemand ein SIGTERM-Signal an den Streaming-Job gesendet hat.

Ist mein Verständnis korrekt? Wenn ja: Wann würde die EMR-Infrastruktur ein SIGTERM senden?

Quelle

2012-08-15 slavi

Haben Sie die CloudWatch-Messwerte überprüft, um zu sehen, ob Sie eine Art IO-Limit erreichen? Aus meiner Erfahrung beginnen einige seltsame Dinge zu passieren, sobald Sie das IO-Limit erreicht haben. Ich weiß nicht, welchen Instanztyp Sie für Ihre Datenknoten verwenden, aber ich würde vorschlagen, auf etwas mit schnellerer E/A-Leistung zu aktualisieren, wenn Sie größere Jobs ausführen. – Edenbauer

Die Sache ist, dass jede Aufgabe CPU-gebunden ist, mit seltenen und sporadischen I/O. Was es tut, ist, dass es eine Datei von S3 lädt und dann für ungefähr 20 Sekunden eine Menge schwerer CPU-Verarbeitung macht. Alle 5 Sekunden speichert er eine weitere (Zwischen-) Datei in S3. Es verwendet einige externe Bibliotheken (lxml, scikit-learn), und ich dachte, dass vielleicht einer von ihnen fehlgeschlagen ist (durch einen Anstieg des Speicherverbrauchs?), Und die EMR-Infrastruktur schickte einen SIGTERM. Um das zu überprüfen, versuche ich die Fälle/Szenarien zu verstehen, wenn EMR einen Prozess SIGTERM werden lässt. – slavi

Ich habe herausgefunden, was passiert ist, also hier ist ein paar Informationen, wenn jemand andere ähnliche Probleme erlebt.

Der Schlüssel zu mir war, die "Jobtracker" Protokolle zu betrachten. Diese leben in Ihrer Aufgabe des logs/Ordner auf S3 unter:

<logs folder>/daemons/<id of node running jobtracker>/hadoop-hadoop-jobtracker-XXX.log.

Es gab mehrere Zeilen der folgenden Art:

2012-08-21 08:07:13,830 INFO org.apache.hadoop.mapred.TaskInProgress 
    (IPC Server handler 29 on 9001): Error from attempt_201208210612_0001_m_000015_0: 
    Task attempt_201208210612_0001_m_000015_0 failed to report status 
    for 601 seconds. Killing!

Also mein Code wurde Timing, und es wurde getötet (es ging über das 10-Minuten-Task-Timeout hinaus). 10 Minuten habe ich keine I/Os gemacht, was sicherlich nicht erwartet wurde (ich würde typischerweise alle 20 Sekunden eine I/O machen).

entdeckte ich dann diesen Artikel:.

http://devblog.factual.com/practical-hadoop-streaming-dealing-with-brittle-code

„In einem unserer wissenschaftlichen Projekte, wir ein paar Hadoop Streaming Jobs haben, die über Rubin und stützen sich auf libxml laufen Dokumente zu analysieren Dies schafft eine perfekte storm of badness - das web ist voll von wirklich schlechtem html und libxml geht gelegentlich in endlose loops oder ourtright segfaults. Bei manchen dokumenten ist es immer segfold. "

Es hat es genagelt. Ich muss eine dieser "libxml in endless loop" -Situationen erleben (ich benutze libxml schwer - nur mit Python, nicht Ruby).

Der letzte Schritt für mich war, den Skip-Modus auszulösen (Anleitung hier: Setting hadoop parameters with boto?).

Quelle

2012-08-22 11:21:26 slavi

Vielen Dank für die Antwort auf Ihr Problem. Dies half mir, ein ähnliches zu debuggen, das ich habe. –

Dito, ich habe einen mrjob-Hadoop-Job ausgeführt, der mit keinem anderen Output als dem, was in der ursprünglichen Frage gepostet wurde, fehlgeschlagen ist. Dies war das einzige nützliche Protokoll, das mir half, die Ursache zu finden (der hadoop2-Mapper-Container hatte zu wenig Speicher). – jonson

Ich lief diese Ausgabe von Amazon EMR ("Subprozess mit Code 143 fehlgeschlagen"). Mein Streaming-Job verwendete PHP curl, um Daten an einen Server zu senden, auf dem der MapReduce-Jobserver nicht Teil der Sicherheitsgruppe war. Deshalb wurde der Reducer ausgeschaltet und getötet. Idealerweise möchte ich meine Jobs zu derselben Sicherheitsgruppe hinzufügen, aber ich habe einfach einen URL-Sicherheits-Token param vor meiner API hinzugefügt.

Quelle

2013-05-06 20:48:58 creoe

Amazon Elastic MapReduce - SIGTERM

Antwort

Verwandte Themen