toilとslurm, singularity使用時の注意点、デバッグのポイントなど
ManabuIshiiXDG_RUNTIME_DIR
slurmがXDG_RUNTIME_DIRを消してしまうようで、それに伴うメッセージがでて、場合によってはエラーがでる
writeLogs
writeLogsを指定するときは、そこがコンテナからもマウントできる必要があるようで、
singularityの場合は、SINGULARITY_BINDの指定が必要なこともある。
あと、このSINGULARITY_BINDで指定するとき、途中がシンボリックリンクの場合、NIGのマシンのhomeなどでは、
readlink -f writeLogsのパス
の結果部分もSINGULARITY_BINDに追加する必要があることがある。
ManabuIshiiHPC環境については以下を読む
XDG_RUNTIME_DIRの仕様？については以下が参考になる。
ワーカーノードのローカル似合ったほうが良いようだという感じはする。
ManabuIshiicwlをtoilをつかって、slurm+singularity環境に投げると、XDG_RUNTIME_DIRという環境変数がないということで、エラーになることがあります。
エラーがおこらないのは、ログインしているノードと計算で割り当てようとしているノードが一致しているときのようです。
この場合は、/run/user/UIDがそんざいするため。
どうも、XDG_RUNTIME_DIR という環境変数を落とすのが、slurmのようで？toilのソースにはそんな感じのことがかいてあります。
このXDG_RUNTIME_DIR が、計算ノードのローカルのファイルシステムで、そこを使って、状態を管理するようです。NFSだと失敗することが多い。。。？そもそもうまくいかない？
このあたり、どうなっているのかを調べる必要があるのですが、
いまのところのWORKAROUNDは、すべての計算ノードとtoil実行ノードに、自分がアクセスできるディレクトリをつくっておいてあげてから実行するとうまくいくっぽいです。
/tmp/
toilの実行時のオプションに --coordinationDir /tmp/$UID
もしかすると、/tmpを指定してもよいかもしれない。
ManabuIshiitoil のメモリ指定、特にJavaが絡むときについてについて
toilで64Gとjavaで64GBと書いたときに、out of memoryがでるときの現象について考えてみた。
toilは、
Gと書くと1000の倍数
Giと書くと1024の倍数
で、計算されたメモリが割り当てられる。
より
--defaultMemory INT
The default amount of memory to request for a job. Only applicable to jobs that do not specify an explicit value for this requirement. Standard suffixes like K, Ki, M, Mi, G or Gi are supported. Default is 2.0Gi
一方
Javaは、
GBとかくと1024の倍数
で、計算されたメモリが割り当てられるようである。
より
-Xms size
ヒープの最小サイズおよび初期サイズ(バイト単位)を設定します。この値は、1024の倍数で、1Mバイトより大きくなければなりません。キロバイトを指定するには文字kまたはK、メガバイトを指定するには文字mまたはM、ギガバイトを指定するには文字gまたはGを付けます。次の例では、様々な単位を使用して、割り当てられたメモリーのサイズを6MBに設定する方法を示します。
Javaで -Xmx64GB と指定したいので、toilで --maxMemory 64G と書くと、５ギガバイト(64Gi-64G)ほど、足りず想定外のエラーがでることがあるとおもわれる。
toilのログをみると、64G指定だと実際にわりあてられたのは、59.0Giのような割当になっていることを確認できました。
ただし本当に足りていないかは未確認
toilに64Gとだけ指定して、Javaで、-Xms64Gと最小を64ギガバイトにするとわかるかもしれない。
参考
実装によってはgrepするとき、おそらく -i をいれたほうが良い
out-of-memory
OutOfMemory
それいがいの考えられるパターンは
"out of memory"
ManabuIshiitoil 5.12.0は、ジョブがおわったかのチェックを直列に実行していくようである。
qstatなど実行中のジョブの監視をしていて、それがなくなったらqacctなど、ジョブ実行後に実行状態を取得するコマンドを実行することになるが、
すくなくとも qstatが終わった直後、qacctがいちうもつかえるわけではないようである。
エラーに気づいて手動で実行すると、普通に表示されることが多く気づきにくい。
ManabuIshiitoil restartをすると初回のジョブは前回と同じパラメータで行うようである。
なので、8GiB指定してエラーになったから、16GiBを指定しても
最初の思考は8GiBである。ここでやめると16GibBが実行されることがわからない。
よくよく、Issuedされたジョブのデータを見るべきである
ManabuIshiislurmに投入したたくさんのジョブをキャンセル
最後のpasteコマンドは、バックスラッシュの後ろに、スペースがある。
カンマ区切りの場合は、カンマにする
grid_engine系なら、qstatとqdelになるのではないか。
scancel $(squeue | grep manabu | awk '{print $1}' | paste -sd\ )
toilデバッグ方法続き
--debugWorkerをつけて、worker.logを確認する。
そもそも、つけたときに、保存できるオプションをしらべておく。
別マシンで実行されるはずなので、共有ディレクトリがよいはず。