memo.txt

2026-03-12

* 共有コードはライブラリファイルに分離するべき? sub.sh, node.sh, core.sh はその
  ファイルを source する。と思ったが長いコードが含まれているのは sub.sh のみで
  ある。node.sh や core.sh はそんなに共有する部分はない様に思われる。強いて分離
  するとすればスクリプト全体を分離することができるような気はする。

2020-09-06

* 実際の実行時間や CPU 使用率、IO待ちなどの統計?

  任意のノードに対して気軽にコマンドを発行する事ができないので、
  もしこれを実現するとしたらジョブ実行の側で自発的に実行情報を
  ファイルシステムに書き込むという事が必要になる。

  またどの様にプロセス群が構築されるのかも確認しておく必要がある。
  実行ノードでプロセスツリーがどの様になっているか確認した

  sbatch で投入したジョブのツリーがあって、
  更に其処から srun で提出れたジョブのツリーが独立に存在する。
  それとは別に sleep 100000000 しているジョブがいる。
  これは監視用のプロセスであろう。

  此処で生じる疑問は sbatch と srun の関係は何かという事である。
  sbatch から直接コマンドを実行してはいけないのか。
  実は srun を使うとまた別の実行ノードに転送される可能性もあるのだろうか。

  ? ローカルで srun を実行すると何処で実行されるのか。

    結果、ローカルでジョブが実行される様だ。ジョブが提出されましたと表
    示されて暫くしてから実行されるのでちゃんとジョブ管理されて実行はさ
    れている。つまり srun は現在のノードでタスクを実行するという物。ノー
    ドが忙しい状態になっていたのはローカルで srun してジョブを提出して
    動かしている人がいるからだろうか。

    sbatch した先で srun すると直接その場で実行する。ジョブが提出され
    ましたなどの表示はないし実行が開始されるまでの時間も比較的短いので
    改めてジョブ管理テーブル上に戻るということもない様である。

2020-09-05

* 各ジョブスケジューラのコマンド比較表
  https://confluence.desy.de/display/IS/SLURM+Rosetta


------------------------------------------------------------------------------
  Done
------------------------------------------------------------------------------

2026-03-12

* 現在投げる時に常に使う cpu core の数が 1 になった状態で投げている。これは良く
  ない。task 毎の core 数を指定できる様にする必要がある。また core としているも
  のは task に名前を変更するべきである。

  どうやら今までは敢えて 1x76 で提出していた様だ。今までは 1 task しかなかった
  のでそれで良かった。つまり今までは何とかして良いようにしていた。でも今複数の
  タスクに分割して提出しようとしているので、結局ここは真面目に実装しなければな
  らない。

  取り敢えずテストも終わって動いている気がする。

* 複数ノードのジョブスケジューラに対する対応

  今までは複数ノードで submit を呼び出しても、実際には各ノードごとに個別のジョ
  ブとして提出するようにしていた。然し、大規模なシステムで大量のノードに対して
  提出したい時には、この方式だと用意にジョブの同時提出数の上限に達してしまう。
  これを回避する為には、やはり真面目に各ジョブ内での複数ノードの利用に対応する
  必要がある。

  取り敢えず実装した。改めて実装について確認する。

  * 取り敢えず --system=direct を用いて実際に実行してみる → 幾つかミスを修正し
    た後に動く様になった。

  * 次に --system=pbs で実際に投げてみて振る舞いを調べる → 未だミスが色々ある。
    emit-submit-header に -b "$rjob_node" を渡していなかった。sub.sh にて複数の
    ノードから開始時刻や終了時刻を書き出していた。

  取り敢えずは良いような気がする。

2020-09-09

* slurm: 結局 sbatch -n ntasks は何を指定するのか。

  これは実際に使う予定のコアの数を指定するのか、
  或いはここに指定した数だけ並列で同じプログラムが起動してしまうのか。
  確認する必要がある。

  →実際に試してみた所、別に ntasks に指定した回数だけ勝手に幾つも実行
  されるという訳ではないようだ。つまり、これはスケジューラに対するアド
  バイスと考えれば良い? 然し、srun と組み合わせた時にどの様に指定する
  のか不明である。sbatch と srun の両方に指定するとその和になってしま
  うのか、或いは srun の和と sbatch の和は別々に勘定されるのか。

  何だかよく分からないので取り敢えずは最初と同じ様に何も指定しない事に
  した。srun で幾つも実行した場合にはそれぞれに -n 1 を指定しているか
  ら恐らく大丈夫? 因みに LiMing の解析スクリプトを見ると内部で並列で計
  算している時であっても無条件に -n 1 を指定している。

  うーん。そもそも sbatch & srun を組み合わせて使うという事自体が謎で
  ある。srun は実行しなくても良い気がするので直接実行する方式にして様
  子を見てみる事にする。

* 実は使い方が間違っていた様な気がする。
  どうも job を submit するとノードを専有できるらしい。
  なので 1 node 1 core で沢山ジョブを投げるのはおかしいという事。

  1 node の中で複数のジョブを投げる様に書き直す必要がある。
  ->並列で実行できる様に書き換えた。

* 2020-09-05 名称について再考

  | 追加の機能をサブコマンドで実装した。
  | すると idtsub submit の様になって冗長である。
  | そもそも idtsub は打ちにくいし発音しにくい。
  | idt に特有の機能なのかというとそうでもない気がする。
  |
  | 元々 sub だったのを idtsub にしたのは
  | git repository に入れて一つのパッケージにする上で
  | 他のホストでも使えるように衝突のない名前に変えたのだった。
  |
  | 世の中には bsub, qsub などがある。これにならって
  | ?sub とするのは一つの案である。
  |
  | もう一つの判断条件は一文字コマンドにしやすいという事である。
  | つまり他の一時もコマンドと被らない文字で始めたい。
  |
  |   a: awk による arithmetic
  |   c: cd
  |   d: date
  |   e: - 過去にコマンド実行に割り当てた事がある
  |   f: fg
  |   g: git
  |   h: history
  |   j: jobs
  |   l: ls -l
  |   m: make
  |   o: open, cygstart, xdgopen
  |   p: ps uaxf
  |   s: stty sane
  |   v: view (less, etc.)
  |   w: w, who
  |   x: startx
  |
  | 使われていない文字は以下の通り
  |   b i k n q r t u y z
  |
  | この中で job scheduler に向いていそうなのは。
  | q = queue を連想させる。b = batch である。
  | 何れも qsub, bsub で既に使われている。
  | この関連では Load Leveler というジョブスケジューラは
  | llsubmit を使っている。つまり l = load である。
  | 実の所、これらと頭文字が被っても良い。
  |
  | 既に似たようなコマンドは沢山ある。
  | つまり現在のホストのプロセスの一覧である。
  | jobs は現在のセッションに関連する物を表示する。
  | ps, top は全てのプロセスに関する情報。
  | cpulook は様々のホストに渡るプロセスの情報。
  |
  | 2020-09-08 結局 alias q=idtsub として使っている。
  | q で始まるとすればどういう物が考えられるだろうか。
  | qman (manager) qcon (controler) que
  | myq, jobque, qjob, qplus, qcov, qrun
  |
  | qrun は良さそうだと思ったが既にそういうコマンドが存在する。
  | qcon, qman は存在しない。quecon や quectl や querun でも良いかも。
  | 個人的には quectl や quecon が良い感じがする。
  | quecon にしようか。

  取り敢えず現在の候補は quecon である。
  暫く置いてよりよい物がなければ改名する。

  或いは cpulook の cpusub に機能を統合する? と思ったが cpulook はリモー
  トとストレージが共有されている事を前提としていない。と考えたがそれで
  も機能を統合してストレージが共有されている前提での機能を追加しても良
  いし、或いはストレージが共有されていなくても動作する様に拡張する事も
  可能である。

2020-09-08

* rsh で実行するモード for debug

  現在 sub.sh の中で srun を実行しているが、これはジョブスケジューラ毎
  に異なる。そもそも srun 等の様に二重の submit が必要なジョブスケジュー
  ラでなければ、sub.sh の様なスクリプトファイルを準備する必要すらなかっ
  た。この様な場合にどの様に構成するのが良かったか。

  というよりジョブスケジューラによってはバッチスクリプトの中に色々な情
  報を書き込まなければならなくて、それはジョブスケジューラに依存するの
  で、結局 sub.sh に該当する物はジョブスケジューラ毎に出力する必要があ
  る。という事など考えると実は現在の構成は仕方がない。

  取り敢えず他のスケジューラで走らせる必要が出て来た時に考えれば良い。

* stat: 古いイベントについて圧縮をするオプションを作る

  bin の中身については圧縮しないか或いは別の圧縮方法にする。
  もしくは hash を保存しておく。hash を保存する様にするのが良い気がする。
  hash を計算して一致していれば同じと見做す。
  というより hash で bin を管理する。
  そして jobdir/bin からはリンクにする。

* stat: option -a で完了したイベントも表示にする
  完了したイベントを表示しないのをデフォルトにする。
  或いは最近のイベントのみを表示する様にする。

* stat: 実行時間を記録する様にしたい

  開始時刻と終了時刻を %F %T %Z で出力していると日付の計算が必要になっ
  て面倒である。%s で unix time を別に出力する様にした方が良い。

2020-09-05

* slurm の標準出力、標準エラー出力は一体どうなっているのか

  既定では slurm-*.out という名前のファイルが一個作られるだけである。
  一方で sbatch のオプションでは -e と -o でそれぞれ別々に指定できる。

  ? 既定では標準エラーは何処に行くのか
    両方とも slurm-*.out に合流して出力される。

  ? -e と -o を指定した時に slurm-*.out はどうなるのか。
    作られない。

  ? -e だけまたは -o だけ指定するとどうなるのか
    -o だけ指定すると両方ともにそこに出力され、slurm-*.out は作成されない。
    -e だけ指定すると標準エラーだけそこに出力され、
    標準出力は依然として slurm-*.out に出力される。

  ? -e と -o に同じファイル名を指定するとどうなるのか
    両方ともそのファイルに出力されるが出力の順序は保たれない。
    但し、互いに上書きし合うという事は起こらない。
    これは何も指定しない場合の slurm-*.out や、
    -o だけ指定した時の出力先でも同様の振る舞いである。

  順序が保たれない事などを考えると自前でリダイレクトした方が良いかもしれない。
  或いは初めから out と err に別々のファイルを指定するという事。

  然し、異なる枠組みの上で動かしたいという事があるかもしれないので、
  この辺りは何れにしても自前で行う様にしておいた方が良い。
  標準エラーと標準出力を別々に保存するかあるいは一緒に保存するかは…
  一緒に保存する事にする。もし別々に保存する必要があるのであれば、
  それは submit する時にユーザの側で指定するべきなのである。

  →自前で redirect する様にしたがどうもそれでも標準出力と
    標準エーラ出力の順序が保たれない様である。
    bash が内部で勝手にバッファリングしているのか。
    或いは OS 自体の問題だろうか。然し OS は linux の筈である。不思議だ。