スライド 1

2012/5/10
スパコン利用者説明会
-ＵＧＥでジョブを投入する
ノウハウ-
この講習の目的
数百・数千のジョブを円滑に実行する方
法を知る
1
Univa Grid Engine(UGE)とは
 グリッドコンピューティングシステムを
構築するソフトウェア。バッチジョブシ
ステムとして機能する
 Sun Grid Engine6.2U5(オープンソー
ス版としては最後のバージョン)から派生
した商用製品。開発にはGrid Engineの
主要な開発メンバーが参加している
 ジョブ投入時のコマンド等はSGEと同じ
2
ＵＧＥを利用する利点
 大量のジョブを逐次、円滑に実行できる
 複数のユーザが同時に大量のジョブを投入し
ても、UGEがスケジューリングを行う
 ジョブが求めるメモリ、CPU等に応じて、
適切なスケジューリングを行う
ＵＧＥを利用するうえでの注意点
 ジョブの並列化などは行わない
 ジョブ投入時のリソース要求宣言を適切に行
わない場合、大規模な計算機のハングアップ
を招く場合がある
3
目次
2. スパコンシステムの構成・特性
3. 投入するジョブの負荷特性を知る
4. ジョブの実行状況を管理する方法を知る
4
ジョブを大量に投入する前に1
 数百～数千のジョブを一度に投入すると、
普段は問題にならない点が問題になる
1ジョブの負荷は僅かでも、同時実行数が多くなると莫大な負荷に
なる。ＣＰＵ負荷、メモリ消費量、Ｉ／Ｏに注意する。
特にＩ／Ｏに注意。
ジョブの負荷を把握していないと、百台単位のノードのハングアッ
プやファイルシステムの障害等、大規模な問題に発展する。
ジョブの数が多くなると、結果の確認等、ジョブを適切に管理する
仕組みが必要になる
5
ジョブを大量に投入する前に2
 ジョブを大量に投入するには準備が必要
 適切な準備が行われれば、ジョブは最速で実行される
 準備を怠ると、ジョブの実行速度が数倍～数十倍遅延
する。過剰な負荷で他のユーザに迷惑をかけ、最悪、
システムを停止させる
ジョブを大量に投入するために
システムの構成・特性を知る
ジョブの負荷特性（CPU・メモリ・I/O）を知る
ジョブの実行状況を管理する方法を知る
6
目次
1. ジョブを大量に投入する前に
3. 投入するジョブの負荷特性を知る
4. ジョブの実行状況を管理する方法を知る
7
スパコンシステム概要
Fatノード
Thinノード
Mediumノード
InfiniBand
高速領域 (Lustre)
省電力領域(NFS)
8
目次
２．２ ファイルシステムの特徴
２．３ ＵＧＥジョブ投入時の上限値
9
各計算ノードの特徴１
 Thinノード
（162台）
 Thinノード（SSD搭載）
（76台）
 Thinノード（SSD, GPU搭載）（64台）
搭載メモリ量：64GB
CPU：Xeon E5-2670(SandyBridge-EP) 2.6GHz
8コア x 2ソケット(16コア)
ノードによってはSSD, GPUを搭載している
1CPUコアの処理能力は3種類のノードの中で最も高性能。
1ジョブあたりの要求メモリ量が搭載メモリ量（64GB）
に収まる処理であれば、このノードを積極的に使用する。
10
各計算ノードの特徴２
 Mediumノード（2台）
搭載メモリ量：2TB
CPU： Xeon E7-4870(Westmere EX) 2.4GHz
10コア x 8ソケット(80コア)
 1ジョブあたりの要求メモリ量が64GB以上～2TB未満
の処理であれば、このノードを使用する
 Fatノード（1台）
搭載メモリ量：10TB
CPU：Xeon E7-8837(Westmere EX) 2.67GHz
8コア x 96ソケット(768コア)
 ２TB以上の共有メモリが必要な処理を実行したい場合、
このノードを使用する
11
目次
２．１ 各計算ノードの特徴
２．３ ＵＧＥジョブ投入時の上限値
12
ファイルシステムの概要
 /lustre1,/lustre2は
共有ファイルシステムで、
全計算ノードから参照できる
 各ユーザのホームディレクトリは
/lustre1,/lustre2に分散配置されている。
 自分のホームの場所は、以下のコマンド
で確認できる
$ ls –l /home/lect01
lrwxrwxrwx 1 root root 20
/lustre1/home/lect01
$
3月 18 15:35 2012 /home/lect01 ->
13
ファイルシステムの詳細
 /lustre1, /lustre2はLustreファイルシステムによ
り構成されている
OSS
(Object Storage Server)
特徴
 分散ファイルシステム
 MDSがメタデータを、OSSが実体を
分散管理する
 データの実体は複数のOSSにストライピン
グすることもできる
データ
実体
MDS
(Meta Data Server)
メタデータ
 数GBの少数ファイルに高速アクセス
 多数のファイル操作はext4より遅い
14
ストライプサイズの変更１
 ファイルを配置するOSSの数を変更できる
（Object Storage Targetの数を変更する）
ストライプサイズ1の場合
 ストライプサイズが1（デフォルト）
の場合、そのファイルの内容は
1つのOSS上に存在する
 ストライプサイズが2以上の場合、
そのファイルの内容は指定した数の
OSS上に分散して存在する
ストライプサイズ12の場合
15
ストライプサイズの変更２
 ストライプサイズの変更はlfsコマンドで行う
lfs setstripe –c ストライプ数 対象ディレクトリ
-c：ストライプ数を指定する。自由に指定できる。
$ mkdir stripe1
$ lfs getstripe stripe1
stripe1
stripe_count:
1 stripe_size:
$ mkdir stripe12
$ lfs setstripe -c 12 stripe12
$ lfs getstripe stripe12
stripe12
stripe_count:
12 stripe_size:
1048576 stripe_offset:
0 stripe_offset:
-1
-1
 通常はストライプサイズは１。400MB/sec程度でアクセス
 ストライプサイズを12にすると、1GB/sec程度でアクセス
16
ストライプサイズの変更基準
 変更が有効である場合
数GB以上のファイルを配置するとき
数MBのファイルを数百個配置するとき
ただし数千個配置するときは、ディレクトリによりファイルを
分散させる必要あり
→ 2倍程度高速化 OSSの負荷を軽減
 変更が有効でない場合
数千個の数B～数KBのファイルを配置するとき
→ 2倍程度遅延 MDS, OSSの負荷が増加
17
数千個のファイルの取り扱い
 Lustreが苦手な処理。特に“ls -l”が苦手
touchコマンドで空のファイルをループで連続して作成
作成後、“ls -l”を実行
ファイル数
作成時間(sec)
“ls –l”実行時間(sec)
1,000
1.2
0.2
10,000
12.8
1.9
100,000
148.6
19.3
118.8
0.9
※HDD(ext4)の場合
100,000
1プロセスでは問題にならないが、多数のプロセスがアクセスす
ると、I/O waitが増え、MDSが過負荷となる
ファイル過多によるMDS遅延は、他ユーザにも影響する
→ 1ディレクトリ内のファイル数を5,000程度とし、ディレク
トリを分割し管理する
18
目次
２．１ 各計算ノードの特徴
２．２ ファイルシステムの特徴
19
ＵＧＥのジョブ投入数の上限
 以下の場合、qsub時にエラーとなる
全ユーザの実行中, 実行待ちジョブ合計数が50,000ジョブを超
過した場合
1ユーザの実行中, 実行待ちジョブ合計数が5,000ジョブを超過
した場合
 特殊なジョブを投入した場合の数え方
MPIジョブは並列度にかかわらず1ジョブとしてカウントされる
アレイジョブはタスク数にかかわらず1ジョブとしてカウントさ
れる
アレイジョブのタスク数は75,000タスクが上限
→ 数千ジョブ投入の際は、必ずアレイジョブとして投入する
20
ジョブの同時実行数上限１
 一般研究用アカウントのユーザは、ジョ
ブスロットを同時に100スロットまで使
用可能（※現在は緩和されている）
 大規模利用アカウントのユーザは、ジョ
ブスロットを同時に500スロットまで使
用可能（※現在は緩和されている）
 qsubによるジョブ投入は投入数の上限値
まで正常にできるが、ジョブは上記制限
の範囲でジョブスロットを使用しつつ進
行する
21
ジョブの同時実行数上限２
 制限状況はqquotaコマンドで確認可能
複数の制限に該当する場合、より厳しい制限が優先
される
以下の例では、100が適用される
$ qquota
resource quota rule limit
filter
------------------------------------------------------------------------------general_limit/1
slots=2/100
users lect01
large_limit/1
slots=2/500
users lect01
$
22
目次
1. ジョブを大量に投入する前に
2. スパコンシステムの構成・特性
4. ジョブの実行状況を管理する方法を知る
23
目次
３．２ ジョブ群の負荷を予測する
３．３ Ｉ／Ｏ負荷を軽減する
３．４ qsubオプションの検討
３．５ ジョブ実行時のお願い
24
ジョブ単体の負荷を計測する１
 計測は、qlogin先のノードでインタラクティブにジョブを
実行する, もしくはdebug.qにジョブを投入して計測する
 CPU
 マルチスレッドの動作の有無を確認
 複数プロセスの起動の有無を確認
→ topコマンドで確認
 メモリ
 利用する最大の仮想メモリサイズを計測
→ ジョブをdebug.qに投入後、qreportコマンドで確認
 I/O
 入出力量（Byte/sec）、ファイル操作回数を確認
→ ラッパーを使用して確認
25
ジョブ単体の負荷を計測する２
 CPUの計測
qlogin先で、ジョブをバックグラウンドで実行中に、
topコマンドで確認する
top –u uid -H
-u uid ：指定したユーザIDのプロセスのみ表示する
-H ：個々のスレッドを別々に表示する
$ ./job01.sh &
$ top –u lect01 –H
(job01.sh内で起動しているコマンドが複数確認できる場合、それはマルチスレッドもし
くはマルチプロセスと判定する)
初めて実行するジョブは、特に慎重に確認する
26
ジョブ単体の負荷を計測する３
 メモリの計測
小規模なジョブをdebug.qに投入する。
その際のジョブIDを記録する
$ qsub –l debug job01.sh
Your job 1905176 (“job01.sh") has been submitted
 ジョブ終了後、qreportコマンドで確認する（ジョブ終
了後、qreportで確認できるまで最大5分の時差がある）
$ qreport -j 1905176|grep maxvmem
maxvmem
2.1G
計測用のジョブは、可能な限り少ないデータで実施する
測定できた場合、データ量を増やしつつ複数回計測する
データ量の変化と消費メモリ量の相関を確認し、実際の処
理対象データでの消費メモリ量予測の参考とする
27
ジョブ単体の負荷を計測する４
 I/Oの計測
ラッパーで計測する
lustre_analyzer.rb “command arg1 arg2 …”
“command”で指定したコマンドが終了するまでにlustreに発生した各種
ファイル操作の回数・入出力量を計測する。計測内容は以下の表の通り。
同ホストで同じタイミングで他のプロセスがlustreにアクセスした場合、
その合算値が表示される
計測結果は標準エラー出力に出力する
open
開いたファイルの数
close
閉じたファイルの数
getattr
ファイル属性の取得数
setattr
ファイル属性の設定数
write_bytes
書き込み量(Bytes)
read_bytes
読み込み量(Bytes)
28
ジョブ単体の負荷を計測する５
 実行例
$ lustre_analyzer.rb “ls -l /usr/local/seq/blast/ncbi/” > /dev/null
-------------The number of Lustre file operations------------fs
open
close getattr setattr write_bytes read_bytes
lustre1
1.0
1.0 2241.0
0.0
726.0 67169280.0
lustre2
0.0
0.0
1.0
0.0
0.0
0.0
-------------------------------------------------------------INFO:
Execute time is 0.4 seconds.
NOTICE: This infomation includes whole operation in this host
-------------------------------------------------------------$
29
ジョブ単体の負荷を計測する６
 ラッパー実行時の注意
 ラッパーの動作の概要は以下の通り
1.引数で与えられたコマンドを実行する前に/proc以下のlustre関連情
報を取得
2.引数で与えられたコマンドを実行
3./proc以下のlustre関連情報を再度取得し、1で取得した情報との差分
を出力
 このような動きであるため、qlogin先のノードでは測定に他ユーザの影
響を受ける可能性が高い。また、時間がかかるジョブであるほど、他
ユーザの影響を受ける可能性が高い
 以下のようにdebug.qに投入して測定するという方法もある
$ qsub –cwd –l debug –S /usr/local/bin/ruby (その他必要なオプション)
/usr/local/bin/lustre_analyzer.rb “./job01.sh”
30
目次
３．１ ジョブ単体の負荷を計測する
３．３ Ｉ／Ｏ負荷を軽減する
３．４ qsubオプションの検討
３．５ ジョブ実行時のお願い
31
ジョブ群の負荷を予測する１
 I/O負荷は、単体ジョブテストで計測した
値に同時実行数を乗じる必要がある
 1ジョブの負荷は僅かでも、100倍、
1,000倍では莫大な負荷になる
lustre
lustre
32
ジョブ群の負荷を予測する２
 前述のlustre_analyzer.rb実行例を
ベースに試算
種別
単体計測値
同時実行数
10
同時実行数
100
同時実行数
1000
open
1
10
100
1000
close
1
10
100
1000
getattr
2,241
22,410
224,100
2,241,000
setattr
0
0
0
0
write_bytes
726B
7KB
70KB
700KB
read_bytes
64MB
640MB
6.4GB
64GB
33
I/O負荷の許容値
 ファイルシステムごとのI/O負荷の許容値は以下の通り
open
1秒あたりのopen総数
30,000で危険な状態
close
1秒あたりのclose総数
30,000で危険な状態
getattr
1秒あたりのgetattr総数
8,000で危険な状態
setattr
1秒あたりのsetattr総数
1,600で危険な状態
この値は
「ファイルシステム全体での負荷の許容値」
であることに注意。
「自分」＋「他の人すべて」で上記の値に収まること
34
目次
３．１ ジョブ単体の負荷を計測する
３．２ ジョブ群の負荷を予測する
３．４ qsubオプションの検討
３．５ ジョブ実行時のお願い
35
I/O負荷を軽減する１

I/O量が多い場合、まず、アルゴリズム修正を検討する。

以下に、同じ操作を異なる方法で実装した処理の計測結果を示す。
※実装例１（good）
$ ./lustre_analyzer.rb "./sample_good.pl"
-------------The number of Lustre file operations------------fs
open
close getattr setattr write_bytes read_bytes
lustre1
0.0
0.0
8.0
0.0
363.0 24312832.0
lustre2
4.0
4.0
3.0
0.0 2450000.0 4178048.0
-------------------------------------------------------------INFO:
Execute time is 0.1 seconds.
NOTICE: This infomation includes whole operation in this host
--------------------------------------------------------------
open
4
close
4
getattr
3
setattr
0
write_bytes
2.4MB
read_bytes
4.0MB
※実装例２（bad）
$ ./lustre_analyzer.rb "./sample_bad.pl"
-------------The number of Lustre file operations------------fs
open
close getattr setattr write_bytes read_bytes
lustre1
1.0
1.0
9.0
0.0 124726.0 8288446464.0
lustre2 250003.0 250003.0 250002.0
0.0 2450000.0 4178048.0
-------------------------------------------------------------INFO:
Execute time is 44.3 seconds.
NOTICE: This infomation includes whole operation in this host
--------------------------------------------------------------
open
250,003
close
250,003
getattr
250,002
setattr
0
write_bytes
2.4MB
read_bytes
4.0MB
36
I/O負荷を軽減する２
 実装例1,2の違いは、openがループの内か外にあるか、のみ。
 ファイルのopen, closeは比較的コストの高い処理であるため、
これだけ大きな差として現れる。
※実装例１（good）
sub do_good{
open(INPUT,“<$IN”);
open(OUTPUT,“>>$OUT”);
while($line=<INPUT>){
if($line =~ /foo/){
print OUTPUT $line;
}
}
close(OUTPUT);
close(INPUT);
}
#入力用ファイルハンドル作成
#出力用ファイルハンドル作成
#一行づつ処理を行う
#fooを含んでいたら
#データ書き込み
#ファイルハンドルを閉じる
#ファイルハンドルを閉じる
※実装例２（bad）
sub do_bad{
open(INPUT,“<$IN”);
while($line=<INPUT>){
if($line =~ /foo/){
open(OUTPUT,“>>$OUT”);
print OUTPUT $line;
close (OUTPUT);
}
}
close(INPUT);
}
#入力用ファイルハンドル作成
#一行づつ処理を行う
#fooを含んでいたら
#出力用ファイルハンドル作成
#データ書き込み
#ファイルハンドルを閉じる
#ファイルハンドルを閉じる
「コストの高い処理」をループ内で実行していないか必ず
チェックする
ループ内で実行する必要のない「コストの高い処理」は、ルー
プの外に出す
37
I/O負荷を軽減する３
 SSDの活用を検討する
“-l ssd”指定時に使用できる実行ホストには、
SSDがディレクトリ/ssdにマウントされている
 /tmp, /lustre1,2と比較して高速にアクセスで
きる。容量は約350GB（実効容量）
 計算ノード上のローカル領域であるため、ジョ
ブを実行したホストからのみ参照可能
 以下のケースで効果が期待できる
中間ファイルを大量に作成する場合
入力ファイルが多数の小さいファイルである場合
38
I/O負荷を軽減する４
 SSD使用時の約束事
ディレクトリ/ssd/ユーザID/を作成して、その中にファイル等
を配置する（例：/ssd/lect01/foo）
使用量の制限はないが、他ユーザとの同時使用の可能性も考慮
し、使用は100GB程度までに抑える
ジョブの終了処理に、作成したファイルを削除する処理を必ず
入れる
あくまで一時的なファイルを配置するために使うため、永続性
は保障されない。メンテナンス等でサーバを再起動した場合、
ファイルは削除される（※検討中）
最終アクセス時間から一定時間（month系キュー：1か月
week系キュー：2週間）経過した場合、ファイルは削除対象と
なる（※検討中）
39
同時実行数を制限する１
 それでもI/O量が多い場合は、同時実行数を抑制する。
この方法が総I/O量を抑制する最も効果的な方法
※アレイジョブの場合
qsub –tc 同時実行数 –t 1-X:Y ジョブ
-tc 同時実行数：アレイジョブの同時実行数の上限を指定する
-t：通常のアレイジョブの指定
以下の指定では500のタスクが動作するが、
同時に進行するタスクは最大で100となる。
$ qsub –tc 100 –t 1-1000:2 job01.sh
40
同時実行数を制限する２
※非アレイジョブの場合
一度にqsubする回数を抑える
ジョブに順序をつける
qsub –N ジョブ名 –hold_jid 投入済みジョブのジョブ名 job02.sh
-N ジョブ名：
今回投入するジョブのジョブ名を指定する
-hold_jid 投入済みジョブのジョブIDまたはジョブ名：
指定したジョブIDまたはジョブ名のジョブが終了するまで、今回投入
するジョブをhold状態にする。指定したジョブが終了すると、自動的
にhold状態は解除され、実行可能な状態となる。
以下の場合、job1 → job2 → job3の順に実行される
$ qsub –N job1 job01.sh
$ qsub –N job2 –hold_jid job1 job02.sh
$ qsub –N job3 –hold_jid job2 job03.sh
41
目次
３．１ ジョブ単体の負荷を計測する
３．２ ジョブ群の負荷を予測する
３．３ Ｉ／Ｏ負荷を軽減する
３．５ ジョブ実行時のお願い
42
CPU・メモリ関連のqsubオプション
検討
 CPU利用量、メモリ利用量は単体ジョブでの計測結果を
そのまま使用して実行計画を作成する
※CPU
マルチスレッドで動作するか？
Yes
“-pe def_slot スレッド数”を付与する
No
特に追加するオプションはない
※メモリ
最大仮想メモリサイズの大きさは？
4GB未満
s_vmem, mem_reqの指定を必要量に変更する
4GB
特に追加するオプションはない
4GB以上
s_vmem, mem_reqの指定を必要量に変更する
64GB以上
2TB未満
s_vmem, mem_reqの指定を必要量に変更する
mediumノードを使用する
2TB以上
s_vmem, mem_reqの指定を必要量に変更する
fatノードを使用する
43
def_slot利用時のリソース要求
 def_slotで利用するスロット数を指定すると、その
分リソース要求量が増える
def_slot
s_vmem, mem_req
実際のリソース要求量
なし
なし（デフォルトの4Gが適用される）
4GB
-pe def_slot 2
なし（デフォルトの4Gが適用される）
8GB
-pe def_slot 4
なし（デフォルトの4Gが適用される）
16GB
なし
-l s_vmem=8G, mem_req=8G
8GB
-pe def_slot 4
-l s_vmem=8G, mem_req=8G
32GB
実際のリソース要求が、使用対象ノードのメモリ量を
超過しないよう注意する。超過した場合、ジョブはサブミット
されても実行されない。
GPUはGPUノードあたり1個であるため、
def_slotと“-l gpu”は組み合わせて指定しない。
44
目次
３．１ ジョブ単体の負荷を計測する
３．２ ジョブ群の負荷を予測する
３．３ Ｉ／Ｏ負荷を軽減する
３．４ qsubオプションの検討
３．５ ジョブ実行時のお願い
45
ジョブ実行時のお願い
いきなり大量のジョブを実行しないこと
負荷の計測およびdebug.qでの小規模のテストを
実施し、問題なく動作することを確認する。
確認できたら本番のキューに投入し、徐々に投入
数を増やしていく
46
目次
1. ジョブを大量に投入する前に
2. スパコンシステムの構成・特性
3. 投入するジョブの負荷特性を知る
47
目次
４．２ ジョブの実行結果を管理する
48
実行状況を確認する１
 ジョブの実行状況はqstatコマンドで確認する
 計算ノードの負荷状況はqhostコマンドで確認
する（“qstat -f”より詳細に確認可能）
qhost –u ユーザID
-u：指定したユーザのジョブを表示する
$ qhost -u lect01
HOSTNAME
ARCH
NCPU NSOC NCOR NTHR LOAD MEMTOT MEMUSE SWAPTO SWAPUS
---------------------------------------------------------------------------------------------global
fi00
lx-amd64
736
92 736 736 0.02 9590.6G
72.9G
8.0G
0.0
m1i
lx-amd64
80
8
80
80 1.00 2019.8G 333.4G
20.0G
0.0
（略）
t292i
lx-amd64
16
2
16
16 0.45
62.9G
3.6G
8.0G
43.3M
job-ID prior
name
user
state submit/start at
queue
master ja-task-ID
---------------------------------------------------------------------------------------------2160251 0.50000 job01
lect01
r
05/02/2012 10:46:57 week_hdd.q MASTER
t293i
lx-amd64
16
2
16
16 0.48
62.9G
2.3G
8.0G
40.5M
（略）
※LOAD（ロードアベレージ）とSWAPUS（スワップ使用量）に注目
49
実行状況を確認する２
 LOADがNCPU（CPUコア数）を超過している
場合
→ ジョブが意図せずにマルチスレッドで動作
している可能性
→ MPIジョブでmachinefile指定をミスしてい
る可能性
 SWAPUSがGB単位になっている場合
→ s_vmem, mem_req指定ミスの可能性
50
実行状況を確認する３
 スパコンの負荷はDDBJのWebページ
「スパコン稼働状況」からも確認可能
http://www.ddbj.nig.ac.jp/system/superco
m/supercom-util.html
51
目次
４．１ ジョブの実行状況を確認する
52
ジョブの実行結果を管理する１
 大量のジョブを実行すると、正常に完了したか否か
の確認に手間がかかる。
 qreportコマンドで一括確認可能
qreport –o ユーザID –N ジョブ名 –b YYYYMMDDhhmm -l
-o：指定したユーザIDのジョブのみ表示する
-N：完全一致するジョブ名のジョブのみ表示する
-l：一覧表示モードで表示する
-b：指定した日時以降のジョブのみ表示する
-e：指定した日時以前のジョブのみ表示する。指定方法は”-b”と同じ
 qreportコマンドを使用することで
実行中に問題が発生したジョブのリストを簡単に作成できる
再投入時の推奨オプションを得られる
（※ジョブを再投入する機能はない）
53
ジョブの実行結果を管理する２
 qreport出力結果の主な項目は以下の通り
task
MPIジョブ, アレイジョブのタスクID
ext
ジョブのexit statusコード。0以外は異常終了を示す
fail
UGEの終了コード。0以外は異常終了を示す
clock
実行時間（ジョブ開始～終了までの所要時間）
mmem
実際に使用した仮想メモリの最大値
Rq, Rm
ジョブ再投入時に推奨されるキュー（ジョブ失敗時のみ表示）
Rm
ジョブ再投入時に推奨されるメモリ要求量（ジョブ失敗時のみ表示）
Ropt
ジョブ再投入時に推奨されるqsubオプション（ジョブ失敗時のみ表示）
54
問い合わせ先
 不明点またはご意見等があれば下記にお問い合わせ
下さい。
遺伝研スパコンSEチーム
Mail：[email protected]
居室：w202
内線：9461
http://www.ddbj.nig.ac.jp/system/supercom/s
upercom-intro.html
55
変更履歴
変更日付
2012/05/10
変更内容
新規作成
56