| On this page |
概要 ¶
ネットワークを走らせる際にあなたが指定したワークを実際に処理させるには、 何か が、実行準備の整ったコマンドを受け取って、その実行環境を構築して、それらのコマンドを実行しなければなりません。 TOPネットワークでは、この 何か は スケジューラ ノードに相当します。
TOPネットワーク内に2個以上のスケジューラノードを配置することができますが、そのネットワークをクックするスケジューラは、TOP Networkノードで指定します。
TOPネットワーク内に複数のスケジューラを配置することで、異なる“プロファイル”をセットアップして、スケジューラ間でそれを切り替えることができます(例えば、小規模なテストをする時にはローカルスケジューラを使用し、プロダクションでフル稼働させる時にはレンダーファームスケジューラに切り替えることができます)。
特定のノードで使用するスケジューラをオーバーライドすることができます。 これによって、ローカルで軽いジョブを実行してファイルシステムの修正を行なうことができるので、ファームにそれらのジョブを送信するオーバーヘッドの負荷を回避することができます(さらに、一部のノードをまったくスケジュールに組ませずにメインプロセスでワークを処理するためのオプションがあります)。 他にも、スケジューラノードは特定のトップレベルのジョブパラメータをオーバーライドすることもできます。
Tip
スケジューラノードのRMBメニューから Set As Default Scheduler を選択することで、デフォルトのスケジューラを切り替えることができます。
新しいTOPネットワークに対して
デフォルトのスケジューラノードは、プロセスキューを使ってワークのスケジュールを組みます。
作業負荷によりますが、これによってオーバーヘッドが小さくなるため、実際にレンダーファームを使用するよりも高速化することができます。
すぐに使えるように、TOPsにはいくつかのレンダーファームパッケージ用のビルトインのスケジューラノードが用意されています(以下参照)。
TOPsは、制御マシンとすべてのサーバーがネットワークファイルシステムを共有している場所で分散されたセットアップのみを扱います。
スケジューラのタイプ ¶
|
デフォルトのスケジューラ:ローカルマシン上のプロセスキューを使って、ワークのスケジュールを組みます。 |
|
|
これはHoudiniの無料の管理ソフトウェアで、小規模なレンダーファームに適しています。
|
|
|
Thinkboxソフトウェア社の計算管理ツールキットです。 |
|
|
Pixar社のレンダー管理ソフトウェアです。 |
|
|
In-Processワークアイテムのスケジューリングを制御します。これはHoudiniプロセス内で非同期的に実行されます。 |
|
|
Binary Alchemy社のレンダー管理ソフトウェアです。 |
カスタムスケジューラ ¶
カスタムスケジューラのバインドを使用することで、他のサードパーティ製または内製のソフトウェアと統合させることができます。
スケジューラのオーバーライド(上書き) ¶
| To... | Do this |
|---|---|
単一ノードで使用するスケジューラをオーバーライドする |
TOP Networkノードで指定されたデフォルトのスケジューラを使用するようにノードの設定を戻すには、このノードの TOP Scheduler Path フィールドを空っぽに設定してください。 |
ノード選択アイコンをクリックすることで、インタラクティブにスケジューラノードを選択することができます。
この方法だと、スケジューラの絶対パスが入ります。Scheduler Job Parms / Properties ¶
| To... | Do this |
|---|---|
単一ノードのジョブ実行パラメータをオーバーライドする |
スケジューラには、スケジュールの組み方とコマンドの実行方法に関する個々のパラメータがあります。それらの設定の一部をノード単位でオーバーライドすることができます。 TOPsはプロパティシステムを使用してスケジューラ設定をオーバーライドします。 例えば、特定のノード内のワークアイテムに対して何かしらの環境変数を設定したいことがあります。
|
自動的にJob ParmsをTOPノードに追加する |
パイプラインでは、場合によっては特定のJob Parmsを常に特定のノードに対して追加する必要があります。
例えば、 n = kwargs['node'] templ = hou.properties.parmTemplate('top', 'hqueue_resources') parmtuple = n.addSpareParmTuple(templ, ('Schedulers','HQueue'), False) parmtuple.set(['sidefx.license.render']) さらに、ワークアイテムアトリビュートを使用してクック時の正しい値を決めるHScriptエクスプレッションをパラメータ値に設定すると良いでしょう。
例えば、ライセンスタイプが # ... parmtuple.set(['`@renderlicense`']) |
ROP Mantra Renderローカルスケジューラのリソースを制限する方法 ¶
Local Schedulerノードで利用可能な計算リソースの数の上限を変更することができます(デフォルトの上限はローカルコンピュータのコア数です)。
-
HQueue SchedulerとLocal Schedulerはどちらともジョブで必要な“CPU数/スロット数”(抽象単位)の概念があり、ジョブを同時に実行する際に使用されるマシン上のスロットの最大数を設定します。
-
例えば、特定のジョブ自体がマルチプロセスまたはマルチスレッドだった場合、4個のコアを使用したいのであれば、そのジョブが4つのスロットを必須とするようにマークすることができます。 Local SchedulerまたはHQueue Schedulerは、最大上限以内で最低でも4つのスロットが“空いている”マシンを確保できた場合にのみそのジョブのスケジュールが組まれます。
-
TOPノードで生成されたジョブで必要なスロット数を指定する:
-
TOPノードを選択します。
-
パラメータエディタで、 Schedulers タブをクリックします。
-
Add Job Parms ボタンを押します。これは、登録されているすべてのスケジューラのメニューを開きます。
-
Local Scheduler 項目を選択します。
-
Scheduler Properties ツリーフォルダ内には、オーバーライド可能なプロパティすべてがスケジューラのタイプ別に含まれています。 Local フォルダ下の Slots Per Work Item を選択します。
-
ボタンを押します。これは、TOPノード上にそれらのプロパティを追加します。 -
そのウィンドウを閉じてから、 Slots Per Work Item のトグルを有効にして、割り当てたいスロット数を設定します。
Note
ワークアイテムアトリビュートに基づいて値を可変させたいのであれば、このパラメータにエクスプレッションを作成すると良いでしょう。
-
-
Local Schedulerの Total Slots では、クック時に同時にTOPsが使用できる最大スロット数を指定することができます。
-
同様に、
HQueue CPUs per Job では、ジョブが専有する'CPU'スロット数を指定することができます。
(将来のバージョンでは、HQueueと同様にデータベースなどの他のリソースタイプの上限を指定することができる予定です)
視覚的なスケジューリングシステム ¶
この図解では、Houdini TOPネットワークの初期クックからローカルマシンまたはファームでのジョブの実行までの作業の流れを示しています。
緑のボックスでは、ノード、ワークアイテム、ディペンデンシーを管理する PDG Graph Core を表現していますが、何の作業も実行しません。
ピンクのブロックは、ジョブが実際に実行される場所を示し、オレンジの PDG Scheduler Python Binding は、PDGワークアイテムをファームスケジューラジョブに変換し、それらの進捗を監視するシステムです。
PDG MQ RPC Server は、ステータスを多重化し、ジョブからのRPCコールの結果をスケジューラバインディングに返す際に使用可能なプログラムです。 これは、アーティストのマシンとジョブが実行されているマシンとの間のファイアーウォールとネットワークの問題を回避するのに役立ちます。
ワークアイテムのオーバーヘッドを削減する方法 ¶
別々のプロセスでオペレーションを開始させるのも、ファーム上でワークのスケジュールを組むのも、ネットワークファイルシステム上にデータを移すのも、どれもこれもTOP内での作業でオーバーヘッド(余計な負荷)が発生します。 一部のノードには、TOPグラフをクックしているプロセス内で小さいジョブを行なうためのオプションがあり、ファーム上でそれらの小さいジョブのスケジュールを組まずに、同じマシン上でそれらのジョブを実行できるようにそれらの小さなワークアイテムをオーバーライドすることができます。
しかし、
HDA Processorノードをローカルで実行させた場合でさえも、そのアセットがすぐにクックを完了するようであれば、それを別々のプロセスで実行させるオーバーヘッドは、パフォーマンス全体に影響を与えてしまいます。
このオーバーヘッドを最適化または回避するために、あなたができる事がいくつかあります:
-
HDA Processorノードの代わりに
ROP Geometryノードを使ってジオメトリを生成し、時間/フレーム番号を使ってWedgeを行なってください。同じHIPファイル内に、アセットをTOP Networkとしてインスタンス化して、SOPネットワークのROP Geometryノードを指定します。 そのROP Geometryノードの ROP Fetch タブにある All Frames in One Batch を有効にします。 これによって、1度に1フレームで全フレーム範囲をクックする単一プロセスが作成されます。通常では、これはシミュレーションで使用しますが、軽量なジオメトリのジョブの効率性を上げる際にもよく使用します。
特定のバッチサイズで試すこともできます。例えば、 All Frames in One Batch の代わりに、1バッチで20フレームを使用するようにすることができます。
-
可能であれば、HDA Processorノードの代わりに
Invokeノードを試してみるのも良いでしょう。Invokeノードは、独自のプロセス内ではなく、TOPグラフをクックしているプロセス内でSOPチェーンをクックします。このInvokeノードの制限事項は、コンパイルブロックでしか使用できないことです。小さい/すぐに処理が終わるようなオペレーションでは、この方が 非常に 効率的です。 -
Local Schedulerを使用する時、サービスを使用することで、HDA ProcessorやROP-Fetchベースの処理を大幅に高速化することができます。
-
ファームを使用する時、ノードのスケジューラオーバーライドを
ローカルスケジューラに設定してローカルマシン上で小さなジョブを実行する方が効率的な場合があります。他にも、Local Schedulerの Total Slots を上げてみるのもよいでしょう。デフォルトの最大プロセス数はローカルマシンが低速にならないように非常に低く設定(コア数/4)されています。 Total Slots を上げるほど、もっと多くのローカルジョブが並列で実行されます。
| See also |
