Der Container läuft über die Speichergrenzen hinaus

In Hadoop v1 habe ich jedem 7-Mapper- und Reduzierer-Steckplatz eine Größe von 1 GB zugewiesen. Meine Mapper und Reduzierer funktionieren einwandfrei. Mein Computer hat 8G Speicher, 8 Prozessor. Bei YARN wurde beim Ausführen derselben Anwendung auf demselben Computer ein Containerfehler angezeigt. Standardmäßig habe ich folgende Einstellungen:

  <property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>1024</value>
  </property>
  <property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>8192</value>
  </property>
  <property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>8192</value>
  </property>

Es gab mir Fehler:

Container [pid=28920,containerID=container_1389136889967_0001_01_000121] is running beyond virtual memory limits. Current usage: 1.2 GB of 1 GB physical memory used; 2.2 GB of 2.1 GB virtual memory used. Killing container.

Ich habe dann versucht, das Speicherlimit in mapred-site.xml festzulegen:

  <property>
    <name>mapreduce.map.memory.mb</name>
    <value>4096</value>
  </property>
  <property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>4096</value>
  </property>

Aber immer noch Fehler:

Container [pid=26783,containerID=container_1389136889967_0009_01_000002] is running beyond physical memory limits. Current usage: 4.2 GB of 4 GB physical memory used; 5.2 GB of 8.4 GB virtual memory used. Killing container.

Ich bin verwirrt, warum die Kartenaufgabe so viel Speicher benötigt. Nach meinem Verständnis reicht 1 GB Speicher für meine Map / Reduce-Aufgabe. Warum verwendet die Aufgabe mehr Speicher, wenn ich dem Container mehr Speicher zuweise? Liegt es daran, dass jede Aufgabe mehr Splits bekommt? Ich halte es für effizienter, die Größe des Containers ein wenig zu verringern und mehr Container zu erstellen, damit mehr Aufgaben parallel ausgeführt werden. Das Problem ist, wie kann ich sicherstellen, dass jedem Container nicht mehr Teilungen zugewiesen werden, als er verarbeiten kann?

Sie sollten auch die maximalen Speicherzuordnungen für MapReduce ordnungsgemäß konfigurieren. Aus diesem HortonWorks-Tutorial :

[...]

Jeder Computer in unserem Cluster verfügt über 48 GB RAM. Ein Teil dieses Arbeitsspeichers sollte für die Verwendung durch das Betriebssystem reserviert sein. Auf jedem Knoten weisen wir 40 GB RAM für> YARN zu, um 8 GB für das Betriebssystem zu verwenden und zu behalten

Für unseren Beispielcluster haben wir den minimalen RAM für einen Container (yarn.scheduler.minimum-Allocation-mb) = 2 GB. Wir werden daher 4 GB für Kartenaufgabencontainer und 8 GB für Aufgabencontainer reduzieren zuweisen.

In mapred-site.xml:

mapreduce.map.memory.mb: 4096

mapreduce.reduce.memory.mb: 8192

Jeder Container führt JVMs für die Aufgaben Map und Reduce aus. Die Größe des JVM-Heapspeichers sollte niedriger als der oben definierte Speicher für Map und Reduce eingestellt werden, damit sie innerhalb der Grenzen des von YARN zugewiesenen Containerspeichers liegen.

In mapred-site.xml:

mapreduce.map.java.opts:: -Xmx3072m

mapreduce.reduce.java.opts:: -Xmx6144m

Mit den obigen Einstellungen wird die Obergrenze des physischen Arbeitsspeichers konfiguriert, den Map- und Reduce-Aufgaben verwenden .

Etwas zusammenfassen:

1. In YARN sollten Sie die mapreduceKonfigurationen verwenden, nicht die mapred. BEARBEITEN: Dieser Kommentar gilt nicht mehr, nachdem Sie Ihre Frage bearbeitet haben.
2. Was Sie konfigurieren, ist tatsächlich, wie viel Sie anfordern möchten, und nicht, wie viel maximal zugewiesen werden soll.
3. Die maximalen Grenzwerte werden mit den java.optsoben aufgeführten Einstellungen konfiguriert .

Schließlich möchten Sie möglicherweise diese andere SO-Frage überprüfen , die ein ähnliches Problem (und eine ähnliche Lösung) beschreibt.

Auf Garnebene wird die Nutzungsrate des virtuellen und physischen Speichers überprüft. Das Problem ist nicht nur, dass die VM nicht über genügend physischen Speicher verfügt. Dies liegt jedoch daran, dass die Nutzung des virtuellen Speichers für einen bestimmten physischen Speicher höher ist als erwartet.

Hinweis : Dies geschieht unter Centos / RHEL 6 aufgrund der aggressiven Zuweisung von virtuellem Speicher.

Es kann entweder gelöst werden durch:

1. Deaktivieren Sie die Überprüfung der Nutzung des virtuellen Speichers, indem Sie yarn.nodemanager.vmem-check-enabled auf false setzen .

2. Erhöhen Sie das VM: PM-Verhältnis, indem Sie das Verhältnis yarn.nodemanager.vmem-pmem auf einen höheren Wert einstellen .

Referenzen :

https://issues.apache.org/jira/browse/HADOOP-11364

http://blog.cloudera.com/blog/2014/04/apache-hadoop-yarn-avoiding-6-time-consuming-gotchas/

Fügen Sie die folgende Eigenschaft in yarn-site.xml hinzu

 <property>
   <name>yarn.nodemanager.vmem-check-enabled</name>
    <value>false</value>
    <description>Whether virtual memory limits will be enforced for containers</description>
  </property>
 <property>
   <name>yarn.nodemanager.vmem-pmem-ratio</name>
    <value>4</value>
    <description>Ratio between virtual memory to physical memory when setting memory limits for containers</description>
  </property>

Ich hatte ein wirklich ähnliches Problem mit HIVE in der EMR. Keine der vorhandenen Lösungen funktionierte für mich - dh keine der Mapreduce-Konfigurationen funktionierte für mich; und auch nicht yarn.nodemanager.vmem-check-enabledauf falsch gesetzt.

Am Ende funktionierte jedoch Folgendes tez.am.resource.memory.mb:

hive -hiveconf tez.am.resource.memory.mb=4096

Eine weitere Einstellung, die Sie in Betracht ziehen sollten, ist yarn.app.mapreduce.am.resource.mb

Ich kann die akzeptierte Antwort aufgrund des schlechten Rufs nicht kommentieren. Ich möchte jedoch hinzufügen, dass dieses Verhalten beabsichtigt ist. Der NodeManager tötet Ihren Container. Es hört sich so an, als würden Sie versuchen, Hadoop-Streaming zu verwenden, das als untergeordneter Prozess der Map-Reduce-Aufgabe ausgeführt wird. Der NodeManager überwacht den gesamten Prozessbaum der Aufgabe. Wenn er mehr Speicher als das in mapreduce.map.memory.mb bzw. mapreduce.reduce.memory.mb festgelegte Maximum verbraucht, wird der Nodemanager die Aufgabe ansonsten beenden Ihre Aufgabe ist es, Speicher zu stehlen, der zu anderen Containern gehört, die Sie nicht wollen.

Während ich mit Spark in EMR arbeitete, hatte ich das gleiche Problem und die Einstellung maximizeResourceAllocation=truehat den Trick gemacht. hoffe es hilft jemandem. Sie müssen es festlegen, wenn Sie den Cluster erstellen. Aus den EMR-Dokumenten:

aws emr create-cluster --release-label emr-5.4.0 --applications Name=Spark \
--instance-type m3.xlarge --instance-count 2 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/mybucket/myfolder/myConfig.json

Wo myConfig.json sagen sollte:

[
  {
    "Classification": "spark",
    "Properties": {
      "maximizeResourceAllocation": "true"
    }
  }
]

Wir haben uns kürzlich auch mit diesem Problem befasst. Wenn das Problem mit dem Mapper-Speicher zusammenhängt, möchte ich einige Dinge vorschlagen, die überprüft werden müssen.

• Überprüfen Sie, ob der Kombinierer aktiviert ist oder nicht . Wenn ja, bedeutet dies, dass die Reduzierungslogik für alle Datensätze ausgeführt werden muss (Ausgabe von Mapper). Dies geschieht im Speicher. Anhand Ihrer Anwendung müssen Sie prüfen, ob das Aktivieren von Combiner hilfreich ist oder nicht. Der Kompromiss besteht zwischen den Netzwerkübertragungsbytes und der benötigten Zeit / Speicher / CPU für die Reduzierungslogik bei der Anzahl der Datensätze 'X'.
  • Wenn Sie der Meinung sind, dass der Kombinierer nicht sehr wertvoll ist, deaktivieren Sie ihn einfach.
  • Wenn Sie einen Kombinierer benötigen und 'X' eine große Zahl ist (z. B. Millionen von Datensätzen), sollten Sie Ihre Teilungslogik ändern (für Standardeingabeformate verwenden Sie weniger Blockgröße, normalerweise 1 Blockgröße = 1 Teilung), um weniger Datensätze einem zuzuordnen Single Mapper.
• Anzahl der Datensätze, die in einem einzelnen Mapper verarbeitet werden. Denken Sie daran, dass alle diese Datensätze im Speicher sortiert werden müssen (die Ausgabe von Mapper ist sortiert). Stellen Sie bei Bedarf mapreduce.task.io.sort.mb (Standard ist 200 MB) auf einen höheren Wert ein. mapred-configs.xml
• Wenn einer der oben genannten Punkte nicht geholfen hat, versuchen Sie, die Mapper-Logik als eigenständige Anwendung auszuführen und die Anwendung mit einem Profiler (wie JProfiler) zu profilieren und festzustellen, wo der Speicher verwendet wird. Dies kann Ihnen sehr gute Einblicke geben.

Ausführen von Garn auf einem Windows Linux-Subsystem mit Ubunto-Betriebssystem, Fehler "Laufen über die Grenzen des virtuellen Speichers hinaus, Container töten" Ich habe das Problem behoben, indem ich die Prüfung des virtuellen Speichers in der Datei yarn-site.xml deaktiviert habe

<property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property>