torque (旧OpenPBS)
概要
- 計算機クラスターのジョブ管理スケジューラ
- 異なるジョブを逐次処理させたい場合に便利 (以下の条件の時とか?)
- メモリや CPU を最大まで使うジョブが複数あり、同時に流すとリソースの取り合いになる。最悪の場合、計算機が落ちる。
- コマンドラインで、 && とか ; で複数のジョブをつなげても実現できるけど、その後に追加のジョブが入った場合は?
- ジョブの終了時間を予測し、マージンをとって、at コマンドで時間を指定してジョブを実行する方法もあるけど、マージン分の時間がもったいない。予測が外れたらリソースの取り合いになる。
- 要はプリンターの印刷状況画面のキュー (印刷データ) が、ジョブに置き換わっただけ。
- 別に計算機クラスターである必要はなく、自分の PC に入れても問題ない
- Ubuntu (Debianも?)では、torque-server (サーバ用)、torque-scheduler (スケジューラ)、torque-mom (ノード用) の 3 つのパッケージで機能する
- スケジューラを変えるなどすることもあるようだ
使い方
- ジョブ投入
$ qsub [オプション] ジョブファイル
- オプション: ジョブファイルのオプションと同じ (ジョブファイル)
- ジョブ一覧
$ qstat [オプション]
Job id Name User Time Use S Queue ------------------------- ---------------- --------------- -------- - ----- 760.servername JOB_NAME1 hoge 311:35:2 R F 762.servername JOB_NAME2 hoge 165:50:2 R F 860.servername JOB_NAME3 fuga 03:03:40 R F
- Job id: 投入順に番号が付けられる (job id を指定するコマンドでは、最初の数字だけで十分)
- Name: ジョブ名
- qsub の -N オプションや、ジョブファイルの PBS -N で指定が可能
- オプションなどで指定されていない場合は、ジョブファイル名の先頭から15文字が使われる
- User: ジョブを投入したユーザ名
- Time: ジョブ処理にかかっている時間 (複数の CPU を指定している場合は、CPU 数に合わせて倍になる)
- S: ステータス
- R: Running (処理中)
- Q: Queue (待機中)
- H: Hold (保留中; ジョブの順番が回ってきても処理しない)
- E: Exit (終了; ?)
- T: 移行中(?)
- W: 待機中(?)
- Queue: ジョブが所属しているキュー
- ジョブ削除
$ qdel ジョブID ...
- ジョブIDは複数指定が可能
- ジョブの順序の入れ替え
$ qorder ジョブID1 ジョブID2
- ジョブの保留(ジョブ実行の順番が回ってきても実行しない)
$ qhold ジョブID1 ジョブID2 ...
- ジョブの保留解除
$ qrls ジョブID1 ジョブID2 ...
- ジョブの実行
$ qrun ジョブID1 ジョブID2 ...
- キューの変更
$ qmove 変更後のキュー名 ジョブID1 ジョブID2 ...
- ジョブの属性変更
$ qalter [投入時の属性オプション] ジョブID1 ジョブID2 ...
- qhold してから qalter、qrls して使うと良い
- ただし、ジョブ内容は変更できない (例えば、特定のノードでのみ有効なジョブコマンドを属性変更したノード先では使えないし、ジョブが
mpirun -n 16
で 16 CPU 使うのに対し、ppn=4
で 4 CPU に変更したりするとエラーで落ちるので注意)
- ジョブにシグナルを送信
$ qsig -s シグナル ジョブID
- STOP: ジョブのサスペンド(ジョブを終了することなく、CPU を空ける; ただし、torque としては CPU が空くわけではないので、次のジョブは実行されない)
- CONT: サスペンドしたジョブの再開
ジョブファイル
- ジョブの内容を書いたシェルスクリプト
- シバン行 (#!/bin/bash など) に続いて、
#PBS …
で始まるジョブ指定 - 例 (bash ベースの場合): \\
- jobfile.sh
#!/bin/bash #PBS -V #PBS -l nodes=1:ppn=4 #PBS -j oe #PBS -N jobname cd ${PBS_O_WORKDIR} 実行コマンド :
- ${PBS_O_WORKDIR}: torque が利用する作業ディレクトリ (必ず書く必要がある)
- オプション (qsub のオプションと同じ)
オプション | 意味 | 値 |
---|---|---|
-V | ジョブを投入した所の環境変数をすべて、ジョブファイルにも適用する | |
-v | ジョブを投入した所の環境変数を指定した分だけ、ジョブファイルにも適用する | |
-q | キューの指定 | |
-j | 出力ファイルの制御 | oe: 標準出力と標準エラーを標準ファイル(*.oジョブID)にまとめる, eo: 標準出力と標準エラーを標準エラーファイル(*.eジョブID)にまとめる, 指定しない場合は、それぞれのファイルが出力される |
-o | 標準出力ファイルのパス | |
-e | 標準エラーファイルのパス | |
-m | メール送信の方法 | 次の文字の組み合わせでメールの送信タイミングを指定 a: ジョブが失敗, b: ジョブが開始, e: ジョブが終了, n: 何もしない |
-M | メールの送信先 | |
-l | リソースの指定(複数ある場合は、カンマで区切る) | walltime=24:00:00 (CPU使用時間制限; CPU数は考慮しない時間) |
nodes=2:ppn=2 (2CPUずつ2ノードを使う; 計4CPU) | ||
nodes=ノード1:ppn=3+ノード2:ppn=2+ノード3:ppn=1 (特定のノードを利用する場合はノード名を書いて + で結合する) | ||
mem, ncpu が使える | ||
-N | ジョブ名 | 指定しない場合は、ジョブファイル名の先頭から15文字 |
導入方法
apt-get による導入
- リポジトリにある torque を apt-get で導入する方法
- 利点
- 設定は面倒だが、インストールは楽。
- 依存関係のパッケージも同時にインストールしてくれる
- 短所
- 特定のバージョンしか扱えない (Ubuntu 14.04 で 2.4.16)
- 2016/07/19 現在、最新版は 6.0.1 であるため、相当古い。
- GPU に対応しているのは、2.5.6, 3.0.2 移行のバージョンであるため、リポジトリにあるものでは GPU マシンへジョブを投入できない。(ノードリストに gpus が入っていると segfault する)
コンパイルによる導入
- ソースからコンパイル、インストールする方法
- 長所
- 最新版や特定のバージョンが使える
- 最新バージョンでは GPU マシンへのジョブ投入ができる
- 短所
- インストールが面倒
- 依存関係などを調べる必要がある
- 設定項目が環境に依存する
キューの設定項目
ノードの追加
/var/spool/torque/server_priv/nodes を編集して、torque サーバプログラムを再起動させて適用する方法もあるが、qmgr でもノードを追加したり削除することができる(ただし、ジョブ実行中のノードでない場合のみ)
$ sudo qmgr > create node ノード名 > set node ノード名 np = CPU数 > set node ノード名 properties = 名前 > quit
- GPU マシンの場合、さらに
set node ノード名 gpus = GPU数
を実行すると GPU の設定ができる (ただし、Torque 2.5.6, 3.0.2 以降に限る) - この後に、
qnodes -a
を実行すると、ノードが追加されたことが分かる他、/var/spool/torque/server_priv/nodes を見ると、追記されている。 - これを応用すると、実行中のキュー以外のキューをサーバプログラムを止めることなく、変更することができる。
- 参考サイト: Managing nodes
その他
- 長時間ジョブを別々のキューで走らせた時に後方にある一方のキューが動かない
- 例:
- CPU が 2 つある計算機上で、CPU を 1 つのみ使い、1 つずつしか走らせることができないキュー A, B にジョブを 3 つずつ投入する予定である (計6ジョブ)
- ジョブ A1, A2, A3
- ジョブ B1, B2, B3
- それぞれのジョブは 25 時間以上かかるものとする
- 先にキュー A に 3 ジョブ (A1, A2, A3) 投入する (CPU は 1 つしか使っていない状態)
- 25時間後に、キュー B の 3 ジョブ (B1, B2, B3) を投入する (本来ならば、キュー B のジョブの処理がすぐに開始されるはず…)
- なぜか、キュー B のジョブが開始しない
- 原因: starving job 機構
- ジョブスケジューラはジョブの処理数を上げるため、指定された walltime が短いジョブから順に処理していく。
- しかし、これだと walltime が長いジョブは、短いジョブが後から次々と投入されると、一向に処理されない状態になる
- これを解決するために、starving job 機構があり、待機状態にあるジョブ (walltime が長いジョブ) が一定時間超えると、そのジョブを優先的に処理しようとする。
- torque の starving job 機構のデフォルトの設定時間は 24 時間
- 例で示した場合、A1 の処理中に 24 時間が経過し、A2, A3 が優先的に処理されるように設定されるが、キュー A はそもそも同時に 1 つしか処理できないため、CPU が 1 つ空いたまま、B1, B2, B3 は待機状態となる。
- キューに使用 CPU や同時ジョブ処理数の制限がかかっていると、例のような問題が起こる
- 解決方法 (/var/spool/torque/sched_priv/sched_config の編集)
- starving job 機構の無効化
help_starving_jobs true ALL
の true を false に変える
- 機構が有効になるまでの時間の変更
max_starve: 24:00:00
の時間を長くする
- job starving 機構の問題の見分け方
$ qstat -f
でジョブ状態を表示し、その中にcomment = Not Running: Draining system to allow starving job to run
とあれば、この問題でジョブが処理されないことになる。
参考サイト
- 特定のノードにのみジョブを流す Node properties