局所性スケジューリング |
|
局所性スケジューリングを使うプロジェクトは、 下記の用意をしなければなりません。
<sticky/> <report_on_rpc/>
<locality_scheduling/>
局所性スケジューリングは以下のように動作します:
<locality_scheduling_sorted_order/>
この仕組みを 局所性スケジューリングと組合わせて使うと、 プロジェクトは前もって仕事を用意しておくのではなく、 スケジューラの要求に応じてその場で仕事を生成することができます。 この仕組みは、config.xml ファイルの中の以下の要素で制御することができます。
<locality_scheduling_wait_period> N </locality_scheduling_wait_period>
X という名前のファイルを持っている計算機が仕事を欲しがったとき、 その X を使う適切な仕事がなければ、スケジューラは下記の 「トリガーファイル」 を作ります。
PROJECT_ROOT/locality_scheduling/need_work/Xそこで、スケジューラは N 秒 待ってから、 その計算機に送出するのに適切な未送出のリザルトないかどうか、もう一度だけ調べてみます。
この仕組みを使うプロジェクトは、前述の need_work ディレクトリを走査する 「on-demand work generator」デーモンのプログラムを用意しなければなりません。 このデーモンはトリガーファイルを見つけると、 それに対応した追加のワークユニットを生成し、 トランジショナーがそれらのワークユニットに対応するリザルトを作ります。 指定値 N 秒のうちに、上記の仕事がほとんどの場合完了するように N を選んで下さい。 (10 秒はそこそこ良い当て推量でしょう)。
この仕事生成のデーモン(work generator)は、仕事を生成したら、 処理を起動した トリガーファイル を消す必要があります。
さらに、この仕事生成のデーモン(あるいは他のプロジェクトのデーモン)が、 ファイル X についてはワークユニットをもう作成できないと判断したら、 下記のまた別の トリガーファイル を作ることができます。
PROJECT_ROOT/locality_scheduling/no_work_available/Xスケジューラはこの種の トリガーファイル を見つけると、 プロジェクトがファイル X について追加の仕事は作れないことが分かるので、 前述の「トリガーファイル作成、待機、再度未送出リザルトを検索」 という手順を省略します。 もちろん、スケジューラは一回めの検索を依然として実施しますから、 トランジショナーが既存の(古い)ワークユニットについて新しいリザルトを作った場合でも、 それらは拾い上げられるようになっています。
File -> workunit -> resultここで、N 台の計算機が稼働しているとして、target_nresults=M であるとします。 理想的な状況なら、M 台の計算機にそれぞれのファイルを送り、 そのファイルを使うリザルトすべてを4台の計算機にやらせたいところです。
もし、one_result_per_user_per_wu の規則を有効にしている場合であると、 ファイルに対応する仕事があっても、それを送付するのに、 特定の参加者を「除外」しなければならない場合もあります。
ファイルを持たない計算機への仕事の割り当ては以下のようにします。
このワーキング・セットは下記のディレクトリで表現します。
PROJECT/locality_scheduling/file_working_set/その中には、ワーキング・セットに含むファイルの名前が入っています。 プロジェクト固有の「working set manager」 デーモンが、この内容を維持管理する責任を負います。
プロジェクトのスケジューラが、 あるファイルに対応する未送出のリザルトがないと気がつくと、 そのファイルと同じ名前で下記のディレクトリにファイルを作ります。
PROJECT/sched_locality/files_no_work/プロジェクトの「working set manager」はこのディレクトリを監視して、 出現した名前に対応するファイルをワーキング・セットから取り除かねばなりません。
ファイル F を持つ計算機に仕事を割り当てるには、
プロジェクトによっては、仕事を徐々に生成したいことがあります。 そのようなときは、下記のディレクトリを定期的に監視して、 そこに登場したファイル名に対して仕事を生成するような 「work generator」デーモンを用意すれば良いのです。
PROJECT/locality_scheduling/need_work/上記の仕組みを働かせるためには、 <locality_scheduling_wait_period> 要素を config.xml ファイルに追加してください。 これをみてスケジューラは、仕事が[その場で]生成されて現れるまで待つ時間の上限を知ります。
注意:すべてのリザルトについて、
同一のプラットフォーム集合内で[計算が可能な]
アプリケーションの版があると仮定しています。
ですから、この想定にあわないという理由で除外されたリザルトは、
可能性を調べ回ることなくその場で断念されてしまいます。
訳注5
最終更新時刻 00:16:04, 2007年04月20日(JST)
Copyright © 2008 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.
Copyright © 2008 Komori Hitoshi(je2bwm at jarl.com).
Japanese translation from English web pages on BOINC.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.