CCJ technical local rules and tips

2003.02.21/2003.05.16

2005.05.27(Objectivityについて削除)

2007.01.24(chtar)

1. HPSS: cftpと pftp
user レベルでのHPSSへのアーカイブのため、ccjではRCFの rftpに相当する
ものとして コマンド cftp を用意しています。
HPSSからの読み出し(pget)は これですべてのfileについて行えます。
書き込み(pput)については userのdirectoryになります。

注意点。
1) 効率化のため、put/get(遅い)ではなく、pput/pgetを使用すること。

2) ファイルサイズ
   効率化のため、100MB以下のサイズのfileが多数ある場合は、100MB以上、
   出来れば1GB程度にtarでまとめること(Overheadを考えると10秒程度で
   転送できてしまう100MBはあまり効率が良いとは言えません）。
   小さい多数のfileはHPSSの性質上取り出しに時間がかかります。
   CCJではHPSSのパラメータを 100MB以上が効率的になるように
   設定しています。

   solaris上では 2GB以上のサイズのfileもつくれますが(そしてHPSSに
   入れることができますが)、いまのところあまりおすすめ
   しません。神経質に linux的な2GB制限を守る必要はありませんが、
   20GBとか 100GBはいまのところやめた方が無難です(次の3も関係します)。


   (07.01.24追記)
    RCF のように hsi/htarが使えます。 htarに関しては COS=6に固定した
     chtarを用意してあるので一般のアーカイブについてはこれを使って下さい。
      ( /opt/ccj/bin/chtar or /usr/local/bin/chtar )
    書き込みおよび読みだし時に cache diskの大きさとの兼ね合いで
    能率が変わるため、 1つの tar fileが100GB程度になるのが無難です。
    1TBは 現状無理です。
    また、tar fileから一部のfileのみ取り出したい場合に、
    普通のtarの場合
    prompt%  tar -xvf t.tar "run50*.txt"
    などの指定で、t.tarのなかから マッチするfileだけとりだせますが、
    htarでは、ワイルドカードはサポートされていないので、できません。
    prompt%  htar -xvf t.tar run501.txt run502.txt run503.txt
    のように、列記する必要があります。


3) セッション継続時間
   一つのsessionで10時間以上になるとsessionが切れます。jobレベルでは
   これはおきないと思いますが、diskにDSTを1TBあげる、等の作業が必要な
   場合に関係します。'mpget * 'で directoryから全部 pgetしようとしても
   12時間たつと途中で切れることになります。そのような作業の場合script
   を書いて 適当にsessionを切るなどが必要です。むやみに大きなfileで 
   転送に10時間を越えてしまうと切れてしまうので、2とも関連します。

#!/bin/tcsh
/usr/local/bin/cftp<< EOF
cd /home/phnxsink/xxxx
pget file1
pget file2
...
bye
EOF

/usr/local/bin/cftp<< EOF
cd /home/phnxsink/xxxx
pget file11
pget file21
...
bye
EOF
....


4) COS
   production結果をdiskにのせたままだが、publicなものとして
   HPSSに保存したい、という場合は COS(class of service:HPSSへの
   fileの保存法のパラメータセット)を選ぶ必要があるので ccj-adminまで
   ご連絡下さい。  そのような場合はこちらで転送します。
   (cftpでは COSは変えられないので。)

   productionなどのまとまった作業で、jobごとに結果fileをHPSSに
   入れたい場合、などは、およそのサイズと数をccj-adminまでご連絡下さい。
   cftp以外の COS が必要な場合もあります。

5) 同時接続制限と cftp_int
   cftpの同時接続数は 40です。それ以上は接続できずに終わります。
   productionなどでその制限がいっぱいになっているときに、個人レベルの
   アーカイブ作業が全くできなくなると困るので、別枠を使用する 
   いわば非常用の'cftp_int' というコマンドがあります(intはinteractive)。
   使い方、効果はまったく同じです。
   こっちは制限が 5 なのでproduction的作業には使わないでください。

2. ccjsun/nfs?(solaris)と ccjgw/ap??(linux)
  ccjsun,ccjgwは login用ゲートウェイなのでjobは流さないでください。
  (root,pawをふくむ。)
  BNLとの大量データ転送のときには ccjnfs[1-3]にloginして、そこの
  diskを直接使用するのがccjsunからNFS経由で行うより効率がよいので、
  そうしてください。fileをtarするなど、I/O boundな仕事も同様です。

3. bbftp
  BNLとの大量データ転送のときには ccjnfs[1-3,10,20]にloginして、bbftpを
  つかってください。
ccjnfs2> bbftp -b -p 10 -uyokkaich -i bbftp-input.txt rftpexp.rhic.bnl.gov
Password: 
ccjnfs2>cat bbftp-input.txt-ccjnfs2
cd /phenix/data07/yokkaich/objy-work/
lcd /ccj/w/data03/temp1/ccjnfs2/
mget dbbkp.targz*

  など。man bbftp もあります。

4. local diskとrcp(x)

DST等がおかれている/ccj/w/data?? (各partition 0.9-1.0TB程度)は
solaris6(または8)のdisk serverにつながっており、linux各nodeからは
NFSでマウントされています。 同時にlinuxから数十のアクセスをうけると 
I/Oのスループットが低下することが わかっているので、jobを流す際は
linux各nodeのローカルディスクである /job_tmpに 自分の名前の
directoryをつくってそこを使ってください。

inputfileをそこにcpしていたのでは NFS経由なので意味がありません。
rcpxというコマンド(中身はrcp、disk serverあたりの同時接続数を最適化
してある)があるのでそれを使ってください。文法はrcpと同じです。
例。
 rcpx ccjnfs2:/ccj/w/data10/xxxxxx.input /job_tmp/yokkaich/temp.dat
 rcpx /job_tmp/yokkaich/temp.result ccjnfs2:/ccj/w/data10/xxxxxx.result

また、host(ccjnfs2など)を指定しないrcp/rcpxはただのcpになって
意味がありませんので 正しく指定してください。どのdiskが
どのhostにぶら下がっているかは dfでわかります。automountなので、
一度のdfで見えなければ、そのdiskをls(することにより mount)
してからdfしてください。

なお、rcpxをつかえば 合計50MB/s程度で disk serverから転送できますが、
NFSで輻輳した場合 10MB/sくらいまで落ちることがあります。このときは
200node以上からaccessされているので 1nodeあたり 0.05MB/sです。ここまで
input速度がおちると cpuも100%つかえず、単独でテストした
ときにくらべ何倍も時間がかかるようなことになります。
とくにccjnfs0(/ccj/u、/ccj/w/r01,r02がついている)でやられると、
home 領域でのfile操作、edit等にも支障がでます。

- FAQ for rcp (030516追加)

rcpは remote host の.cshrc, .profile 等がoutputを出すと
正常に動作しません(manに書いてあります)。
.cshrcのoutputとは、自分でそのように書いたつもりがなくても、
たとえば 「シェル変数が定義されていない」といった
エラーメッセージなどが該当します。これで rcp/rcpx
が使えなかった例が最近2つほどあったので追加しておきます。

   
5. batch queueing system LSF
RCFとおなじくLSFが使われています。今まで出たトラブルと
その対策について。

1) limit
queueごとの limitなどは 
コマンド bqueues/bqueues -l でわかります。ここででてくるMAXは
queueing system 自体が 同時実行数を制限してるのであって、userが
それ以上 submitしてはいけないというような数ではありません。
大量にsubmitするときにはそのためのscriptをつくったりすると
おもいますが、そこでの工夫で 自分が走らせているjobの数の制限を
する必要はありません(して悪いわけでもないですが、走らせたい総数が
最初から分かっている方が調整もしやすいので)。

また、どうしても同時最大実行数を幾つにしてほしい、という必要が
ありましたらccj-adminまでご連絡下さい。特定のqueueを設定します。
設定は一分でできるのでご遠慮なく。


2) black hole
linux 各nodeのsystem errorなどで、LSFからはそのnodeは正常にみえるが、
jobはすぐ死んでしまう、というような状況があります。RCFではAFSのトラブル
などでおこっていました。CCJでもnodeのdisk troubleで同様の状況に
なることがありました。こうなると、たとえば 100cpu にたいして 10時間
かかるjobを 200 submitした場合 99jobは正常終了するが、こわれた1cpuに 
dispatchされたjobはすぐ死に、待っていた次のjobがdispatch されるがすぐ死に、
また...のくりかえしで 101jobは 異常終了します。これを 通称 black hole
などといいます。もしそれに気付いた場合のuserレベルでの対策ですが、
bsub -m (host名) sleep 100000
などどうでもよいjobで そこの nodeをふさいでしまい、
ccj-adminに連絡してください。
こちらでは とりあえず LSFからそのnodeをはずしてしまいます。

3) queue 'trash'
上同様 nodeの troubleなどで、 いつまでたってもjobが終わらない
(ようにみえる)ことがあります。rsh (host) ps などでみて、
cpuを食っていなければ、そういう状態の可能性があります。こういうのは
bkillで殺せます。
さらに、bjobsでは見えるが、bkill で殺そうとしても死なない状態もあります。
こうなると たいていnodeをrebootするしかないのですが、そうすると入っていた
jobは 原則として再実行されます。それが必要ない場合(自分でもうやって
しまった、など)は、コマンドbswitchでそのjobをqueue trashに移してください。
そうすると再実行されません。

bswitch trash jobID
です。jobIDは bjobsでわかります。

2),3)で書かれているようなトラブルはとくに 2002/4月あたりから
目立ってきたので経験のある方も多いと思いますが、
hard的対策(マザーボード交換など)を経て最近かなり頻度が下がっているとは
思います。