2013/02/22 スパコン利用者説明会 UGEでジョブを投入する ノウ … · $ ./job01.sh...

スパコン利用者説明会 -ＵＧＥでジョブを投入する ノウハウ-

2013/02/22

この講習の目的

数百・数千のジョブを円滑に実行する方法を知る

1

Univa Grid Engine(UGE)とは

グリッドコンピューティングシステムを構築するソフトウェア。バッチジョブシステムとして機能する

Sun Grid Engine6.2U5(オープンソース版としては最後のバージョン)から派生した商用製品。開発にはGrid Engineの主要な開発メンバーが参加している

ジョブ投入時のコマンド等はSGEと同じ

2

ＵＧＥを利用する利点 大量のジョブを逐次、円滑に実行できる

複数のユーザが同時に大量のジョブを投入しても、UGEがスケジューリングを行う

ジョブが求めるメモリ、CPU等に応じて、適切なスケジューリングを行う

3

ＵＧＥを利用するうえでの注意点 ジョブの並列化などは行わない

ジョブ投入時のリソース要求宣言を適切に行わない場合、大規模な計算機のハングアップを招く場合がある

目次

2. スパコンシステムの構成・特性

3. 投入するジョブの負荷特性を知る

4. ジョブの実行状況を管理する方法を知る

4

ジョブを大量に投入する前に1

数百～数千のジョブを一度に投入すると、普段は問題にならない点が問題になる

5

1ジョブの負荷は僅かでも、同時実行数が多くなると莫大な負荷になる。ＣＰＵ負荷、メモリ消費量、Ｉ／Ｏに注意する。 特にＩ／Ｏに注意。

ジョブの負荷を把握していないと、百台単位のノードのハングアップやファイルシステムの障害等、大規模な問題に発展する。

ジョブの数が多くなると、結果の確認等、ジョブを適切に管理する仕組みが必要になる

ジョブを大量に投入する前に2

ジョブを大量に投入するには準備が必要

適切な準備が行われれば、ジョブは最速で実行される

準備を怠ると、ジョブの実行速度が数倍～数十倍遅延する。過剰な負荷で他のユーザに迷惑をかけ、最悪、システムを停止させる ジョブを大量に投入するために

6

システムの構成・特性を知る

ジョブの負荷特性（CPU・メモリ・I/O）を知る

ジョブの実行状況を管理する方法を知る

目次

1. ジョブを大量に投入する前に

3. 投入するジョブの負荷特性を知る

4. ジョブの実行状況を管理する方法を知る

7

スパコンシステム概要

8

Thinノード

Mediumノード

Fatノード

高速領域 (Lustre) 省電力領域(NFS)

InfiniBand

目次

２．２ ファイルシステムの特徴

２．３ ＵＧＥジョブ投入時の上限値

9

各計算ノードの特徴１

Thinノード （162台）

Thinノード（SSD搭載） （76台）

Thinノード（SSD, GPU搭載）（64台）

10

搭載メモリ量：64GB CPU：Xeon E5-2670(SandyBridge-EP) 2.6GHz

8コア x 2ソケット(16コア) ノードによってはSSD, GPUを搭載している

1CPUコアの処理能力は3種類のノードの中で最も高性能。1ジョブあたりの要求メモリ量が搭載メモリ量（64GB）に収まる処理であれば、このノードを積極的に使用する。

各計算ノードの特徴２ Mediumノード（2台）

Fatノード（1台）

11

搭載メモリ量：2TB CPU： Xeon E7-4870(Westmere EX) 2.4GHz

10コア x 8ソケット(80コア)

搭載メモリ量：10TB CPU：Xeon E7-8837(Westmere EX) 2.67GHz

8コア x 96ソケット(768コア)

1ジョブあたりの要求メモリ量が64GB以上～2TB未満の処理であれば、このノードを使用する

２TB以上の共有メモリが必要な処理を実行したい場合、このノードを使用する

目次

２．１ 各計算ノードの特徴

２．３ ＵＧＥジョブ投入時の上限値

12

ファイルシステムの概要

/lustre1,/lustre2は 共有ファイルシステムで、 全計算ノードから参照できる

各ユーザのホームディレクトリは/lustre1,/lustre2に分散配置されている。

自分のホームの場所は、以下のコマンドで確認できる

13

$ ls –l /home/lect01

lrwxrwxrwx 1 root root 20 3月 18 15:35 2012 /home/lect01 ->

/lustre1/home/lect01

$

ファイルシステムの詳細

/lustre1, /lustre2はLustreファイルシステムにより構成されている

14

MDS (Meta Data Server)

OSS (Object Storage Server)

データ 実体

メタデータ

特徴 分散ファイルシステム MDSがメタデータを、OSSが実体を

分散管理する データの実体は複数のOSSにストライピン

グすることもできる

数GBの少数ファイルに高速アクセス 多数のファイル操作はext4より遅い

ストライプカウントの変更１

ファイルを配置するOSSの数を変更できる（Object Storage Targetの数を変更する）

ストライプカウントが1（デフォルト） の場合、そのファイルの内容は 1つのOSS上に存在する

ストライプカウントが2以上の場合、 そのファイルの内容は指定した数の OSS上に分散して存在する

15

ストライプカウント1の場合

ストライプカウント12の場合

ストライプカウントの変更２

ストライプカウントの変更はlfsコマンドで行う

16

$ mkdir stripe1

$ lfs getstripe stripe1

stripe1

stripe_count: 1 stripe_size: 1048576 stripe_offset: -1

$ mkdir stripe12

$ lfs setstripe -c 12 stripe12

$ lfs getstripe stripe12

stripe12

stripe_count: 12 stripe_size: 0 stripe_offset: -1

lfs setstripe –c ストライプ数 対象ディレクトリ

-c：ストライプ数を指定する。自由に指定できる。

通常はストライプカウントは１。400MB/sec程度でアクセス ストライプカウントを12にすると、1GB/sec程度でアクセス

ストライプカウントの変更基準

変更が有効である場合

変更が有効でない場合

17

数GB以上のファイルを配置するとき 数MBのファイルを数百個配置するとき

ただし数千個配置するときは、ディレクトリによりファイルを分散させる必要あり → 2倍程度高速化 OSSの負荷を軽減

数千個の数B～数KBのファイルを配置するとき → 2倍程度遅延 MDS, OSSの負荷が増加

数千個のファイルの取り扱い

Lustreが苦手な処理。特に“ls -l”が苦手

18

ファイル数 作成時間(sec) “ls –l”実行時間(sec)

1,000 1.2 0.2

10,000 12.8 1.9

100,000 148.6 19.3

※HDD(ext4)の場合

100,000 118.8 0.9

1プロセスでは問題にならないが、多数のプロセスがアクセスすると、I/O waitが増え、MDSが過負荷となる

ファイル過多によるMDS遅延は、他ユーザにも影響する → 1ディレクトリ内のファイル数を5,000程度とし、ディレクトリを分割し管理する

touchコマンドで空のファイルをループで連続して作成 作成後、“ls -l”を実行

目次

２．１ 各計算ノードの特徴

２．２ ファイルシステムの特徴

19

ＵＧＥのジョブ投入数の上限

以下の場合、qsub時にエラーとなる

特殊なジョブを投入した場合の数え方

20

全ユーザの実行中, 実行待ちジョブ合計数が50,000ジョブを超過した場合

1ユーザの実行中, 実行待ちジョブ合計数が5,000ジョブを超過した場合

MPIジョブは並列度にかかわらず1ジョブとしてカウントされる アレイジョブはタスク数にかかわらず1ジョブとしてカウントさ

れる アレイジョブのタスク数は75,000タスクが上限

→ 数千ジョブ投入の際は、必ずアレイジョブとして投入する

ジョブの同時実行数上限１

一般研究用アカウントのユーザは、ジョブスロットを同時に100スロットまで使用可能（※現在は緩和されている）

大規模利用アカウントのユーザは、ジョブスロットを同時に500スロットまで使用可能（※現在は緩和されている）

qsubによるジョブ投入は投入数の上限値まで正常にできるが、ジョブは上記制限の範囲でジョブスロットを使用しつつ進行する

21

ジョブの同時実行数上限２

制限状況はqquotaコマンドで確認可能 複数の制限に該当する場合、より厳しい制限が優先される 以下の例では、100が適用される

22

$ qquota

resource quota rule limit filter

-------------------------------------------------------------------

-------------

general_limit/1 slots=2/100 users lect01

large_limit/1 slots=2/500 users lect01

$

目次

1. ジョブを大量に投入する前に

2. スパコンシステムの構成・特性

4. ジョブの実行状況を管理する方法を知る

23

目次

３．２ ジョブ群の負荷を予測する

３．３ Ｉ／Ｏ負荷を軽減する

３．４ qsubオプションの検討

３．５ ジョブ実行時のお願い 24

ジョブ単体の負荷を計測する１

計測は、qlogin先のノードでインタラクティブにジョブを実行する, もしくはdebug.qにジョブを投入して計測する

25

マルチスレッドの動作の有無を確認 複数プロセスの起動の有無を確認

→ topコマンドで確認

利用する最大の仮想メモリサイズを計測 → ジョブをdebug.qに投入後、qreportコマンドで確認

入出力量（Byte/sec）、ファイル操作回数を確認 → ラッパーを使用して確認

CPU

メモリ

I/O

ジョブ単体の負荷を計測する２

CPUの計測 qlogin先で、ジョブをバックグラウンドで実行中に、 topコマンドで確認する

26

$ ./job01.sh &

$ top –u lect01 –H

(job01.sh内で起動しているコマンドが複数確認できる場合、それはマルチスレッドもしくはマルチプロセスと判定する)

top –u uid -H

-u uid ：指定したユーザIDのプロセスのみ表示する

-H ：個々のスレッドを別々に表示する

初めて実行するジョブは、特に慎重に確認する

ジョブ単体の負荷を計測する３

メモリの計測 小規模なジョブをdebug.qに投入する。 その際のジョブIDを記録する

ジョブ終了後、qreportコマンドで確認する（ジョブ終了後、qreportで確認できるまで最大5分の時差がある）

27

$ qsub –l debug job01.sh

Your job 1905176 (“job01.sh") has been submitted

$ qreport -j 1905176|grep maxvmem

maxvmem 2.1G

計測用のジョブは、可能な限り少ないデータで実施する 測定できた場合、データ量を増やしつつ複数回計測する データ量の変化と消費メモリ量の相関を確認し、実際の処

理対象データでの消費メモリ量予測の参考とする

ジョブ単体の負荷を計測する４

I/Oの計測 ラッパーで計測する

28

open 開いたファイルの数

close 閉じたファイルの数

getattr ファイル属性の取得数

setattr ファイル属性の設定数

write_bytes 書き込み量(Bytes)

read_bytes 読み込み量(Bytes)

lustre_analyzer.rb “command arg1 arg2 …”

“command”で指定したコマンドが終了するまでにlustreに発生した各種ファイル操作の回数・入出力量を計測する。計測内容は以下の表の通り。

同ホストで同じタイミングで他のプロセスがlustreにアクセスした場合、その合算値が表示される

計測結果は標準エラー出力に出力する

ジョブ単体の負荷を計測する５

実行例

29

$ 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

--------------------------------------------------------------

$

ジョブ単体の負荷を計測する６

ラッパー実行時の注意

30

$ qsub –cwd –l debug –S /usr/local/bin/ruby (その他必要なオプション)

/usr/local/bin/lustre_analyzer.rb “./job01.sh”

ラッパーの動作の概要は以下の通り 1.引数で与えられたコマンドを実行する前に/proc以下のlustre関連情報を取得 2.引数で与えられたコマンドを実行 3./proc以下のlustre関連情報を再度取得し、1で取得した情報との差分を出力

このような動きであるため、qlogin先のノードでは測定に他ユーザの影響を受ける可能性が高い。また、時間がかかるジョブであるほど、他ユーザの影響を受ける可能性が高い

以下のようにdebug.qに投入して測定するという方法もある

目次

３．１ ジョブ単体の負荷を計測する

３．３ Ｉ／Ｏ負荷を軽減する

３．４ qsubオプションの検討

３．５ ジョブ実行時のお願い 31

ジョブ群の負荷を予測する１

I/O負荷は、単体ジョブテストで計測した値に同時実行数を乗じる必要がある

1ジョブの負荷は僅かでも、100倍、1,000倍では莫大な負荷になる

32

lustre lustre

ジョブ群の負荷を予測する２

前述のlustre_analyzer.rb実行例を ベースに試算

33

種別 単体計測値 同時実行数

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

I/O負荷の許容値

ファイルシステムごとのI/O負荷の許容値は以下の通り

34

この値は 「ファイルシステム全体での負荷の許容値」 であることに注意。 「自分」＋「他の人すべて」で上記の値に収まること

open 1秒あたりのopen総数 30,000で危険な状態

close 1秒あたりのclose総数 30,000で危険な状態

getattr 1秒あたりのgetattr総数 8,000で危険な状態

setattr 1秒あたりのsetattr総数 1,600で危険な状態

目次

３．１ ジョブ単体の負荷を計測する

３．２ ジョブ群の負荷を予測する

３．４ qsubオプションの検討

３．５ ジョブ実行時のお願い 35

I/O負荷を軽減する１ I/O量が多い場合、まず、アルゴリズム修正を検討する。

以下に、同じ操作を異なる方法で実装した処理の計測結果を示す。

36

$ ./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

--------------------------------------------------------------

※実装例１（good）

$ ./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

--------------------------------------------------------------

※実装例２（bad）

open 4

close 4

getattr 3

setattr 0

write_bytes 2.4MB

read_bytes 4.0MB

open 250,003

close 250,003

getattr 250,002

setattr 0

write_bytes 2.4MB

read_bytes 4.0MB

I/O負荷を軽減する２

実装例1,2の違いは、openがループの内か外にあるか、のみ。

ファイルのopen, closeは比較的コストの高い処理であるため、これだけ大きな差として現れる。

37

sub do_good{

open(INPUT,“<$IN”); #入力用ファイルハンドル作成

open(OUTPUT,“>>$OUT”); #出力用ファイルハンドル作成

while($line=<INPUT>){ #一行づつ処理を行う

if($line =~ /foo/){ #fooを含んでいたら

print OUTPUT $line; #データ書き込み

}

}

close(OUTPUT); #ファイルハンドルを閉じる

close(INPUT); #ファイルハンドルを閉じる

}

sub do_bad{

open(INPUT,“<$IN”); #入力用ファイルハンドル作成

while($line=<INPUT>){ #一行づつ処理を行う

if($line =~ /foo/){ #fooを含んでいたら

open(OUTPUT,“>>$OUT”); #出力用ファイルハンドル作成

print OUTPUT $line; #データ書き込み

close (OUTPUT); #ファイルハンドルを閉じる

}

}

close(INPUT); #ファイルハンドルを閉じる

}

※実装例１（good） ※実装例２（bad）

「コストの高い処理」をループ内で実行していないか必ずチェックする

ループ内で実行する必要のない「コストの高い処理」は、ループの外に出す

I/O負荷を軽減する３

SSDの活用を検討する “-l ssd”指定時に使用できる実行ホストには、SSDがディレクトリ/ssdにマウントされている

/tmp, /lustre1,2と比較して高速にアクセスできる。容量は約350GB（実効容量）

計算ノード上のローカル領域であるため、ジョブを実行したホストからのみ参照可能

以下のケースで効果が期待できる

38

中間ファイルを大量に作成する場合 入力ファイルが多数の小さいファイルである場合

I/O負荷を軽減する４

SSD使用時の約束事

39

ディレクトリ/ssd/ユーザID/を作成して、その中にファイル等を配置する（例：/ssd/lect01/foo）

使用量の制限はないが、他ユーザとの同時使用の可能性も考慮し、使用は100GB程度までに抑える

ジョブの終了処理に、作成したファイルを削除する処理を必ず入れる

あくまで一時的なファイルを配置するために使うため、永続性は保障されない。メンテナンス等でサーバを再起動した場合、ファイルは削除される（※検討中）

最終アクセス時間から一定時間（month系キュー：1か月 week系キュー：2週間）経過した場合、ファイルは削除対象となる（※検討中）

同時実行数を制限する１

それでもI/O量が多い場合は、同時実行数を抑制する。 この方法が総I/O量を抑制する最も効果的な方法

40

$ qsub –tc 100 –t 1-1000:2 job01.sh

qsub –tc 同時実行数 –t 1-X:Y ジョブ

-tc 同時実行数：アレイジョブの同時実行数の上限を指定する

-t：通常のアレイジョブの指定

※アレイジョブの場合

以下の指定では500のタスクが動作するが、 同時に進行するタスクは最大で100となる。

同時実行数を制限する２

41

$ qsub –N job1 job01.sh

$ qsub –N job2 –hold_jid job1 job02.sh

$ qsub –N job3 –hold_jid job2 job03.sh

qsub –N ジョブ名 –hold_jid 投入済みジョブのジョブ名 job02.sh

-N ジョブ名：

今回投入するジョブのジョブ名を指定する

-hold_jid 投入済みジョブのジョブIDまたはジョブ名：

指定したジョブIDまたはジョブ名のジョブが終了するまで、今回投入するジョブをhold状態にする。指定したジョブが終了すると、自動的にhold状態は解除され、実行可能な状態となる。

以下の場合、job1 → job2 → job3の順に実行される

※非アレイジョブの場合 一度にqsubする回数を抑える ジョブに順序をつける

目次

３．１ ジョブ単体の負荷を計測する

３．２ ジョブ群の負荷を予測する

３．３ Ｉ／Ｏ負荷を軽減する

３．５ ジョブ実行時のお願い 42

CPU・メモリ関連のqsubオプション検討 CPU利用量、メモリ利用量は単体ジョブでの計測結果を

そのまま使用して実行計画を作成する

43

※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ノードを使用する

def_slot利用時のリソース要求

def_slotで利用するスロット数を指定すると、その分リソース要求量が増える

44

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”は組み合わせて指定しない。

目次

３．１ ジョブ単体の負荷を計測する

３．２ ジョブ群の負荷を予測する

３．３ Ｉ／Ｏ負荷を軽減する

３．４ qsubオプションの検討

３．５ ジョブ実行時のお願い 45

ジョブ実行時のお願い

46

負荷の計測およびdebug.qでの小規模のテストを実施し、問題なく動作することを確認する。

確認できたら本番のキューに投入し、徐々に投入数を増やしていく

いきなり大量のジョブを実行しないこと

目次

1. ジョブを大量に投入する前に

2. スパコンシステムの構成・特性

3. 投入するジョブの負荷特性を知る

47

目次

４．２ ジョブの実行結果を管理する

48

実行状況を確認する１

ジョブの実行状況はqstatコマンドで確認する

計算ノードの負荷状況はqhostコマンドで確認する（“qstat -f”より詳細に確認可能）

49

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（スワップ使用量）に注目

実行状況を確認する２

LOADがNCPU（CPUコア数）を超過している場合 → ジョブが意図せずにマルチスレッドで動作している可能性 → MPIジョブでmachinefile指定をミスしている可能性

SWAPUSがGB単位になっている場合 → s_vmem, mem_req指定ミスの可能性

50

実行状況を確認する３

スパコンの負荷はDDBJのWebページ 「スパコン稼働状況」からも確認可能 http://sc.ddbj.nig.ac.jp/index.php/ja-nig-statistics

51

目次

４．１ ジョブの実行状況を確認する

52

ジョブの実行結果を管理する１

大量のジョブを実行すると、正常に完了したか否かの確認に手間がかかる。

qreportコマンドで一括確認可能

53

qreport –o ユーザID –N ジョブ名 –b YYYYMMDDhhmm -l

-o：指定したユーザIDのジョブのみ表示する

-N：完全一致するジョブ名のジョブのみ表示する

-l：一覧表示モードで表示する

-b：指定した日時以降のジョブのみ表示する

-e：指定した日時以前のジョブのみ表示する。指定方法は”-b”と同じ

実行中に問題が発生したジョブのリストを簡単に作成できる 再投入時の推奨オプションを得られる

（※ジョブを再投入する機能はない）

qreportコマンドを使用することで

ジョブの実行結果を管理する２

qreport出力結果の主な項目は以下の通り

54

task MPIジョブ, アレイジョブのタスクID

ext ジョブのexit statusコード。0以外は異常終了を示す

fail UGEの終了コード。0以外は異常終了を示す

clock 実行時間（ジョブ開始～終了までの所要時間）

mmem 実際に使用した仮想メモリの最大値

Rq, Rm ジョブ再投入時に推奨されるキュー（ジョブ失敗時のみ表示）

Rm ジョブ再投入時に推奨されるメモリ要求量（ジョブ失敗時のみ表示）

Ropt ジョブ再投入時に推奨されるqsubオプション（ジョブ失敗時のみ表示）

問い合わせ先

不明点またはご意見等があれば下記にお問い合わせ下さい。

遺伝研スパコンSEチーム

Mail：sc-info@nig.ac.jp

居室：w202

内線：9461

http://sc.ddbj.nig.ac.jp/index.php

55

56

変更履歴

変更日付 変更内容

2012/05/10 新規作成

2013/02/22 「ストライプカウント」と表記すべき箇所を「ストライプサイズ」と表記していたため修正