web-dev-qa-db-ja.com

コンテナがメモリ制限を超えて実行されています

Hadoop v1では、サイズが1GBの各マッパーおよびレデューサースロットを割り当てました。マッパーおよびレデューサーは正常に動作します。私のマシンには8Gメモリ、8プロセッサが搭載されています。 YARNでは、同じマシンで同じアプリケーションを実行すると、コンテナエラーが発生しました。デフォルトでは、次の設定があります。

  <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>

エラーが発生しました：

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.

次に、mapred-site.xmlでメモリ制限を設定しようとしました。

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

しかし、まだエラーが発生しています：

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.

Mapタスクがこれほど多くのメモリを必要とする理由がわかりません。私の理解では、1GBのメモリで私のmap/reduceタスクに十分です。コンテナにより多くのメモリを割り当てると、タスクはより多くを使用するのはなぜですか？各タスクがより多くの分割を取得するためですか？コンテナのサイズを少し小さくし、より多くのコンテナを作成して、より多くのタスクを並行して実行する方が効率的だと思います。問題は、各コンテナが処理できる以上の分割を割り当てられないようにする方法です。

hadoopmapreduceyarnmrv2
70
Lishu

MapReduceの最大メモリ割り当ても適切に構成する必要があります。 このHortonWorksチュートリアル から：

[...]

クラスター内の各マシンには48 GBのRAMがあります。このRAMの一部は、オペレーティングシステムの使用のために予約する必要があります。各ノードで、YARNに40 GB RAMを割り当て、オペレーティングシステム用に8 GBを使用および保持します

サンプルクラスターの場合、コンテナの最小RAM（yarn.scheduler.minimum-allocation-mb）= 2 GBがあります。したがって、Mapタスクコンテナには4 GBを割り当て、Reduceタスクコンテナには8 GBを割り当てます。

Mapred-site.xmlで：

mapreduce.map.memory.mb：4096

mapreduce.reduce.memory.mb：8192

各コンテナは、MapおよびReduceタスク用のJVMを実行します。 JVMヒープサイズは、YARNによって割り当てられたコンテナメモリの境界内に収まるように、上記で定義したMap and Reduceメモリよりも小さく設定する必要があります。

Mapred-site.xmlで：

mapreduce.map.Java.opts：-Xmx3072m

mapreduce.reduce.Java.opts：-Xmx6144m

上記の設定は、MapおよびReduceタスクが使用する物理RAMの上限を構成します。

まとめると：

  1. YARNでは、mapreduceの設定ではなく、mapredの設定を使用する必要があります。 EDIT：質問を編集したため、このコメントは適用されなくなりました。
  2. 構成しているのは、実際に要求する量であり、割り当てる最大値ではありません。
  3. 最大制限は、上記のJava.opts設定で構成されます。

最後に、この他の SOの質問 をチェックして、同様の問題（および解決策）を説明することもできます。

90
cabad

縦および物理メモリ使用率の糸レベルでのチェックがあります。問題は、VMに十分な物理メモリがないことだけではありません。しかし、仮想メモリの使用量は、指定された物理メモリの予想を超えているためです。

注：これは、Centos/RHEL 6で仮想メモリが積極的に割り当てられているために発生しています。

次のいずれかの方法で解決できます。

  1. yarn.nodemanager.vmem-check-enabledをfalse;に設定して、仮想メモリ使用量チェックを無効にします。

  2. yarn.nodemanager.vmem-pmem-ratioをより高い値に設定して、VM：PMの比率を増やします。

参照：

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

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

yarn-site.xmlに次のプロパティを追加します

 <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>
42
Sanjiv

EMRでHiveを使用すると、本当に似たような問題がありました。既存のソリューションはどれも私にとってはうまくいきませんでした。つまり、mapreduce構成はどれもうまくいきませんでした。また、yarn.nodemanager.vmem-check-enabledをfalseに設定しませんでした。

ただし、動作するようになったのはtez.am.resource.memory.mbの設定でした。たとえば、

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

微調整を検討する別の設定はyarn.app.mapreduce.am.resource.mbです

12
hiroprotagonist

評判が悪いため、受け入れられた回答についてコメントすることはできません。ただし、この動作は仕様によるものです。 NodeManagerはコンテナを強制終了しています。 map-reduceタスクの子プロセスとして実行されているhadoopストリーミングを使用しようとしているようです。 NodeManagerはタスクのプロセスツリー全体を監視し、mapreduce.map.memory.mbまたはmapreduce.reduce.memory.mbでそれぞれ設定されている最大メモリ量より多くのメモリを消費する場合、Nodemanagerがタスクを強制終了することを期待します。あなたのタスクは、他のコンテナに属するメモリを盗むことです。

8
Brian G

EMRでsparkを操作しているときに同じ問題が発生し、maximizeResourceAllocation=trueを設定するとうまくいきませんでした。それが誰かを助けることを願っています。クラスターを作成するときに設定する必要があります。 EMR docs： から

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

MyConfig.jsonの場所：

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

また、最近この問題に直面しました。問題がマッパーのメモリに関連している場合、チェックする必要があることを提案したいいくつかのことがあります。

  • combinerが有効になっているかどうかを確認します？ 「はい」の場合、すべてのレコードでリデュースロジックを実行する必要があることを意味します（マッパーの出力）。 これはメモリ内で発生します。アプリケーションに基づいて、コンバイナの有効化が役立つかどうかを確認する必要があります。トレードオフは、レコードの 'X'個のリデュースロジックのネットワーク転送バイトと所要時間/メモリ/ CPUの間です。
    • コンバイナがあまり価値がないと感じた場合は、単に無効にしてください。
    • コンバイナーが必要で、「X」が膨大な数（たとえば数百万のレコード）の場合、分割ロジック（デフォルトの入力形式ではブロックサイズを小さく、通常は1ブロックサイズ= 1分割）を変更して、より少ないレコードをシングルマッパー。
  • 1つのマッパーで処理されるレコードの数。これらのレコードはすべて、メモリ内でソートする必要があることに注意してください（マッパーの出力はソートされます）。必要に応じて、mapreduce.task.io.sort.mb（デフォルトは200MB）をより高い値に設定することを検討してください。 mapred-configs.xml
  • 上記のいずれかが役に立たない場合は、マッパーロジックをスタンドアロンアプリケーションとして実行し、プロファイラー（JProfilerなど）を使用してアプリケーションのプロファイルを作成し、メモリが使用される場所を確認してください。これにより、非常に優れた洞察が得られます。
1
Rathan