0

MapReduce1 を実行して、Hadoop クラスター (CDH4) を構成する最善の方法を見つけるのに苦労しています。ノードごとに複数のマッパーを実行できないほど大量のJavaヒープスペースを必要とする両方のマッパーを実行する必要がある状況にありますが、同時にジョブを実行できるようにしたいですノードごとに多くのマッパーの恩恵を受けることができます。

Cloudera 管理 UI を使用してクラスターを構成していますが、Max Map Tasks と mapred.map.child.java.opts はかなり静的な設定のようです。

私が望んでいるのは、毎回 MapReduce サービスを再構成する必要なく、両方の種類のジョブに対応できる、X GB を使用できるヒープ スペース プールのようなものです。1 つのマッパーを実行する場合、X GB ヒープを割り当てる必要があります。8 つのマッパーを実行する場合、X/8 GB ヒープを割り当てる必要があります。

最大仮想メモリと Cgroup メモリのソフト/ハード制限の両方を検討しましたが、どちらも希望どおりにはなりません。最大仮想メモリはタスクごとの設定であるため、有効ではありません。Cgroup の設定には問題があります。これは、個々のタスクがより多くのヒープを持っている場合に実際にはそれらをより少ない量のヒープに制限するようには見えず、むしろタスクが大量のメモリを使用してプロセスを強制終了することを許可するためです。

達成したい動作を構成できますか?

4

1 に答える 1

2

(PS Hadoop 2 / CDH4: では、このプロパティの新しい名前を使用する必要がありますmapreduce.map.java.opts。ただし、両方とも認識されるはずです。)

クラスターで構成する値は単なるデフォルトです。ジョブごとにオーバーライドできます。CDH のデフォルト値のままにするか、通常のマッパーにとって適切な値に設定する必要があります。

ハイメモリ ジョブの場合のみ、クライアント コードで、サブミットする前にオブジェクトに設定mapreduce.map.java.optsします。ConfigurationJob

MR2/YARN を実行している場合、「スロット」ではなくコンテナー メモリによってスケジュールされるため、答えはより複雑になります。したがって、記憶は、新しい、異なる特性を持つ新しい、異なる方法で全体像に入ります。(それは私を混乱させます。私は Cloudera にいます。)

リソース要件をメモリの観点から表現するので、ある意味では良いでしょう。これはここでは良いことです。mapreduce.map.memory.mbこれはプロセス全体に許可されるメモリであるため、JVM ヒープ サイズよりも約 30% 大きいサイズに設定することもできます。同じように、ハイメモリ ジョブの場合は、より高く設定します。その後、Hadoop は、実行するマッパーの数を決定し、ワーカーを配置する場所を決定し、構成ごとにできるだけ多くのクラスターを使用できます。独自の架空のリソース プールに煩わされる必要はありません。

MR1 では、これを正しく行うのが難しくなります。mapreduce.tasktracker.map.tasks.maximum概念的には、ヒープ設定とともに、ワーカーあたりのマッパーの最大数を 1 に設定する必要がありますが、これは高メモリ ジョブのためだけです。クライアントがこれをジョブごとに要求または設定できるかどうかはわかりません。意味が分からないので疑問です。実行するマッパーの数を制御することはもちろん、調べるためにハックする必要があるという理由だけで、マッパーの数を制御することによってこれに実際にアプローチすることはできません。

OSレベルの設定は役に立たないと思います。ある意味で、これらは MR2 / YARN がリソースのスケジューリングについて考える方法に似ています。(MR2 に移動して) MR2 のリソース制御を使用し、あとは MR2 に任せるのが最善の策かもしれません。

于 2013-09-14T04:19:47.750 に答える