blog

Hadoop YARN設定パラメータ プロファイリング (4)-Fair Scheduler 関連パラメータ

まず、yarn-site.xmlで、設定パラメータを次のように設定します。...

Jul 5, 2025 · 5 min. read
シェア

まず、yarn-site.xmlで設定パラメータを設定します。

1つは主にスケジューラレベルのパラメータを設定するために使用される yarn-site.xml で、もう1つは主に各キューのリソース量、重み、その他の情報を設定するために使用されるカスタム設定ファイルです。

1.設定ファイル yarn-site.xml

yarn.scheduler.fair.allocation.file:カスタムXMLコンフィギュレーション・ファイルの場所。このファイルは主に、リソースの量や重みなど、各キューのプロパティを記述するために使用されます。

yarn.scheduler.fair.user-as-default-queue:アプリケーションがキュー名を指定していない場合に、ユーザ名をそのキュー名として指定するかどうかを設定します。falseに設定するか、設定しない場合、不明なキューを持つ全てのアプリケーションはデフォルトのキューに投入されます、デフォルト値はtrueです。

yarn.scheduler.fair.preemption: 先取りメカニズムを有効にするかどうか、デフォルト値はfalseです。

yarn.scheduler.fair.sizebasedweight:キュー内でリソースを割り当てる場合、デフォルトではフェアなポーリングを用いて各アプリケーションにリソースを割り当てますが、このパラメータはリソースを割り当てる別の方法を提供します。このパラメータは、リソースを割り当てる別の方法を提供します: アプリケーションリソースの要求数に従って、つまり、必要なリソース数が多いほど、より多くのリソースが割り当てられます。デフォルトでは、このパラメータの値は False です。

yarn.scheduler.assignmultiple: バルク割り当て機能を有効にするかどうか。ノード上に大量のリソースが存在する場合、割り当ては1回でも複数回でも可能です。デフォルトでは、このパラメータの値はfalseです。

yarn.scheduler.fair.max.assign:バッチ割り当てが有効な場合、一度に割り当てるコンテナの数を指定できます。デフォルトでは、このパラメータの値は-1で、制限がないことを示します。

yarn.scheduler.fair.locality.threshold.node:スキップ可能な***リソースのスケジューリング機会で、アプリケーションがノード上のリソースを要求するときに受け入れることができます。割り当てポリシーに従ってノード上のリソースをアプリケーションに割り当てることができる場合、そのノードがアプリケーションの期待するノードでない場合、アプリケーションは割り当て機会をスキップして、アプリケーションのニーズを満たすノードが利用可能になるまで一時的に他のアプリケーションにリソースを割り当てることを選択できます。通常、ハートビートは1つのスケジューリング機会を表し、このパラメータはスキップされるノード総数の割合を表します。デフォルトでは-1.0であり、スケジューリング機会がスキップされないことを示します。

yarn.scheduler.fair.locality.threshold.rack:アプリケーションがラック上のリソースを要求するときに受け入れることができる、スキップ可能な***リソースのスケジューリング機会。

yarn.scheduler.increment-allocation-mb:メモリの正規化単位、デフォルトは1024です。これは、コンテナが1.5GBのリソースを要求した場合、スケジューラによってceiling(1.5GB / 1GB) * 1G = 2GBに正規化されることを意味します。

yarn.scheduler.increment-allocation-vcores:仮想CPU定期化ユニット、デフォルトは1、メモリ定期化ユニットと同様の意味です。

2.カスタム設定ファイル

Fair Schedulerでは、ユーザはキュー情報を設定ファイルにのみ記述することができ、管理者は各キューに対して以下のオプションを設定することができます:

minResources: 最低資源保証量。"X mb, Y vcores" の形式で設定され、キューの最低資源保証量が満たされない場合、同じレベルの他のキューに優先して資源を取得します。異なるスケジューリングポリシーの場合,最小資源保証は異なる意味を持ちます. fair ポリシーの場合,メモリ資源のみが考慮され,すなわち,キューが使用するメモリ資源がその最小資源を超えた場合,それは満たされたとみなされます.

maxResources: 使用可能なリソースの最大量。公平なスケジューラは、各キューで使用されるリソースの量が、そのキューで使用可能なリソースの最大量を超えないようにします。

maxRunningApps: 実行中のアプリケーションの最大数。この数を制限することで、同時に実行されるマップタスクが多すぎる場合に中間出力がディスクをバーストするのを防ぐことができます。

minSharePreemptionTimeout: 最小共有先取りタイムアウト。この時間内にプールが最小量未満のリソースを使用していた場合、プールはリソースの先取りを開始します。

aclSubmitApps: キューにアプリケーションを投入することができる Linux ユーザまたはユーザグループのリスト。デフォルトでは "*" となっており、どのユーザもキューにアプリケーションを投入することができます。つまり、子キューのリストは親キューのリストを継承します。この属性を設定する場合、ユーザやユーザグループは", "で区切られ、ユーザとユーザグループは空白で区切られます。例えば、"user1, user2 group1,group2 "のようになります。

aclAdministerApps: このキューの管理者のリスト。キューの管理者は、キュー内のリソースやアプリケーションを管理することができます。

管理者は、個々のユーザに対してmaxRunningJobs属性を追加して、同時に実行できるアプリケーションの最大数を制限することもできます。さらに、管理者は上記の属性のデフォルト値を以下のパラメータで設定できます:

userMaxJobsDefault: ユーザのmaxRunningJobsプロパティのデフォルト値。

defaultMinSharePreemptionTimeout : キューの minSharePreemptionTimeout プロパティのデフォルト値。

defaultPoolSchedulingMode: キューの schedulingMode プロパティのデフォルト値。

fairSharePreemptionTimeout: フェアシェア先取りタイムアウト。リソースプールがこの時間、フェアシェアの半分未満しか使用していない場合、リソースの先取りを開始します。

HadoopクラスタにqueueA、queueB、queueCの3つのキューを設定し、queueBとqueueCはqueueAの子キューであるとします。をカスタム設定ファイルに以下のように記述します:

<allocations> 
  <queue name=”queueA”> 
    <minResources>100 mb, 100 vcores</minResources> 
    <maxResources>150 mb, 150 vcores</maxResources> 
    <maxRunningApps>200</maxRunningApps> 
    <minSharePreemptionTimeout>300</minSharePreemptionTimeout> 
    <weight>1.0</weight> 
    <queue name=”queueB”> 
       <minResources>30 mb, 30 vcores</minResources> 
       <maxResources>50 mb, 50 vcores</maxResources> 
    </queue> 
    <queue name=”queueC”> 
      <minResources>50 mb, 50 vcores</minResources> 
      <maxResources>50 mb, 50 vcores</maxResources> 
    </queue> 
  </queue> 
  <user name=”userA”> 
    <maxRunningApps>400</maxRunningApps> 
  </user> 
  <userMaxAppsDefault>40</userMaxAppsDefault> 
  <fairSharePreemptionTimeout>6000</fairSharePreemptionTimeout> 
</allocations> 
Read next

信頼できるJava scriptプログラマーの資質

この記事は著者がClouderaで働いていた2010年に書かれたもので、node.jsが流行る前で、まだ多くの人がこの地味なスクリプトに関心を持っていませんでした。この記事では、node.jsを真剣に考えるべきであり、信頼できるフロントエンドエンジニアになるために何をすべきかを提案しています。時代は少し遠く感じますが、この記事で指摘されていることのいくつかは今でも通用するものです。

Jul 5, 2025 · 5 min read