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

Question 1

Hadoop v1では、7つのマッパーとレデューサースロットをそれぞれ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 / reduceタスクには1GBのメモリで十分です。コンテナにより多くのメモリを割り当てると、タスクがより多くを使用するのはなぜですか？各タスクがより多くの分割を取得するためですか？より多くのタスクが並行して実行されるように、コンテナーのサイズを少し小さくして、より多くのコンテナーを作成する方が効率的だと思います。問題は、各コンテナに処理できる以上の分割が割り当てられないようにするにはどうすればよいですか？

Question 2

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

[...]

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

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

mapred-site.xmlの場合：

mapreduce.map.memory.mb：4096

mapreduce.reduce.memory.mb：8192

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

mapred-site.xmlの場合：

mapreduce.map.java.opts： -Xmx3072m

mapreduce.reduce.java.opts： -Xmx6144m

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

要約すると：

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

最後に、同様の問題（および解決策）を説明するこの他のSOの質問を確認することをお勧めします。

Question 3

仮想メモリと物理メモリの使用率について、ヤーンレベルでチェックが行われます。問題は、VMに十分な物理メモリがないことだけではありません。ただし、これは、特定の物理メモリの仮想メモリ使用量が予想よりも多いためです。

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

それは次のいずれかによって解決できます：

糸.nodemanager.vmem-check-enabledをfalseに設定して、仮想メモリ使用量チェックを無効にします。
糸.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-sumption-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>

Question 4

EMRでHIVEを使用すると、非常によく似た問題が発生しました。現存するソリューションはどれも私にはうまくいきませんでした。つまり、mapreduce構成はどれも私にはうまくいきませんでした。どちらもyarn.nodemanager.vmem-check-enabledfalseに設定しませんでした。

ただし、最終的に機能したのは、次のような設定tez.am.resource.memory.mbでした。

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

微調整を検討するもう1つの設定は yarn.app.mapreduce.am.resource.mb

Question 5

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

Question 6

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

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"
    }
  }
]

Question 7

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

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

Question 8

UbuntuOSを搭載したWindowsLinuxサブシステムでyarnを実行すると、「仮想メモリの制限を超えて実行中、コンテナが強制終了されます」というエラーが発生しました。ファイルyarn-site.xmlで仮想メモリチェックを無効にすることで解決しました。

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

Question 9

私は個人的にチェックしていませんが、hadoop-yarn-container-virtual-memory-understanding-and-solving-container-is-running-beyond-virtual-memory-limits-errorsは非常に合理的に聞こえます

私yarn.nodemanager.vmem-pmem-ratioはより高い値に変更することで問題を解決しました、そして私はそれに同意します：

もう1つのあまり推奨されない解決策は、yarn.nodemanager.vmem-check-enabledをfalseに設定して、仮想メモリチェックを無効にすることです。