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 ...
    • 投入時の属性オプション とは、qsub に与えた -l-j-m-N などのノードやジョブタイトルなどの属性 (詳しくは、 ジョブオプション を参照)
    • 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 を見ると、追記されている。
  • これを応用すると、実行中のキュー以外のキューをサーバプログラムを止めることなく、変更することができる。
  • 長時間ジョブを別々のキューで走らせた時に後方にある一方のキューが動かない
    • 例:
      1. CPU が 2 つある計算機上で、CPU を 1 つのみ使い、1 つずつしか走らせることができないキュー A, B にジョブを 3 つずつ投入する予定である (計6ジョブ)
        • ジョブ A1, A2, A3
        • ジョブ B1, B2, B3
        • それぞれのジョブは 25 時間以上かかるものとする
      2. 先にキュー A に 3 ジョブ (A1, A2, A3) 投入する (CPU は 1 つしか使っていない状態)
      3. 25時間後に、キュー B の 3 ジョブ (B1, B2, B3) を投入する (本来ならば、キュー B のジョブの処理がすぐに開始されるはず…)
      4. なぜか、キュー 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 とあれば、この問題でジョブが処理されないことになる。