• 検索結果がありません。

この講習の目的 数百 数千のジョブを円滑に実行する方法を知る 1

N/A
N/A
Protected

Academic year: 2021

シェア "この講習の目的 数百 数千のジョブを円滑に実行する方法を知る 1"

Copied!
57
0
0

読み込み中.... (全文を見る)

全文

(1)

スパコン利用者説明会

-UGEでジョブを投入する

ノウハウ-

(2)

この講習の目的

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

法を知る

(3)

Univa Grid Engine(UGE)とは

グリッドコンピューティングシステムを

構築するソフトウェア。バッチジョブシ

ステムとして機能する

Sun Grid Engine6.2U5(オープンソー

ス版としては最後のバージョン)から派生

した商用製品。開発にはGrid Engineの

主要な開発メンバーが参加している

(4)

UGEを利用する利点

大量のジョブを逐次、円滑に実行できる

複数のユーザが同時に大量のジョブを投入し

ても、UGEがスケジューリングを行う

ジョブが求めるメモリ、CPU等に応じて、

適切なスケジューリングを行う

UGEを利用するうえでの注意点

ジョブの並列化などは行わない

ジョブ投入時のリソース要求宣言を適切に行

わない場合、大規模な計算機のハングアップ

を招く場合がある

(5)

目次

2.

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

3.

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

(6)

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

数百~数千のジョブを一度に投入すると、

普段は問題にならない点が問題になる

1ジョブの負荷は僅かでも、同時実行数が多くなると莫大な負荷に

なる。CPU負荷、メモリ消費量、I/Oに注意する。

特にI/Oに注意。

ジョブの負荷を把握していないと、百台単位のノードのハングアッ

プやファイルシステムの障害等、大規模な問題に発展する。

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

仕組みが必要になる

(7)

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

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

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

準備を怠ると、ジョブの実行速度が数倍~数十倍遅延

する。過剰な負荷で他のユーザに迷惑をかけ、最悪、

システムを停止させる

ジョブを大量に投入するために

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

ジョブの負荷特性(CPU・メモリ・I/O)を知る

(8)

目次

1.

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

3.

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

(9)

スパコンシステム概要

Thinノード Mediumノード Fatノード 高速領域 (Lustre) 省電力領域(NFS) InfiniBand

(10)

目次

2.2 ファイルシステムの特徴

(11)

各計算ノードの特徴1

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)

に収まる処理であれば、このノードを積極的に使用する。

(12)

各計算ノードの特徴2

Mediumノード(2台)

Fatノード(1台)

搭載メモリ量: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未満

の処理であれば、このノードを使用する

(13)

目次

2.1 各計算ノードの特徴

(14)

ファイルシステムの概要

/lustre1,/lustre2は

共有ファイルシステムで、

全計算ノードから参照できる

各ユーザのホームディレクトリは

/lustre1,/lustre2に分散配置されている。

自分のホームの場所は、以下のコマンド

で確認できる

$ ls –l /home/lect01

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

(15)

ファイルシステムの詳細

/lustre1, /lustre2はLustreファイルシステムによ

り構成されている

MDS

(Meta Data Server)

OSS

(Object Storage Server)

データ 実体 メタデータ

特徴

 分散ファイルシステム

 MDSがメタデータを、OSSが実体を

分散管理する

 データの実体は複数のOSSにストライピン

グすることもできる

 数GBの少数ファイルに高速アクセス

 多数のファイル操作はext4より遅い

(16)

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

ファイルを配置するOSSの数を変更できる

(Object Storage Targetの数を変更する)

ストライプカウントが1(デフォルト)

の場合、そのファイルの内容は

1つのOSS上に存在する

ストライプカウントが2以上の場合、

そのファイルの内容は指定した数の

OSS上に分散して存在する

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

(17)

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

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

$ 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:ストライプ数を指定する。自由に指定できる。

 通常はストライプカウントは1。400MB/sec程度でアクセス

 ストライプカウントを12にすると、1GB/sec程度でアクセス

(18)

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

変更が有効である場合

変更が有効でない場合

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

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

ただし数千個配置するときは、ディレクトリによりファイルを

分散させる必要あり

→ 2倍程度高速化 OSSの負荷を軽減

数千個の数B~数KBのファイルを配置するとき

→ 2倍程度遅延 MDS, OSSの負荷が増加

(19)

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

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

ファイル数

作成時間(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”を実行

(20)

目次

2.1 各計算ノードの特徴

(21)

UGEのジョブ投入数の上限

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

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

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

過した場合

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

した場合

MPIジョブは並列度にかかわらず1ジョブとしてカウントされる

アレイジョブはタスク数にかかわらず1ジョブとしてカウントさ

れる

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

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

(22)

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

一般研究用アカウントのユーザは、ジョ

ブスロットを同時に100スロットまで使

用可能(※現在は緩和されている)

大規模利用アカウントのユーザは、ジョ

ブスロットを同時に500スロットまで使

用可能(※現在は緩和されている)

qsubによるジョブ投入は投入数の上限値

まで正常にできるが、ジョブは上記制限

の範囲でジョブスロットを使用しつつ進

行する

(23)

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

制限状況はqquotaコマンドで確認可能

複数の制限に該当する場合、より厳しい制限が優先

される

以下の例では、100が適用される

$ qquota

resource quota rule limit filter

---

general_limit/1 slots=2/100 users lect01 large_limit/1 slots=2/500 users lect01 $

(24)

目次

1.

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

2.

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

(25)

目次

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

3.3 I/O負荷を軽減する

3.4 qsubオプションの検討

3.5 ジョブ実行時のお願い

(26)

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

計測は、qlogin先のノードでインタラクティブにジョブを

実行する, もしくはdebug.qにジョブを投入して計測する

 マルチスレッドの動作の有無を確認

 複数プロセスの起動の有無を確認

→ topコマンドで確認

 利用する最大の仮想メモリサイズを計測

→ ジョブをdebug.qに投入後、qreportコマンドで確認

 入出力量(Byte/sec)、ファイル操作回数を確認

CPU

メモリ

I/O

(27)

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

CPUの計測

qlogin先で、ジョブをバックグラウンドで実行中に、

topコマンドで確認する

$ ./job01.sh & $ top –u lect01 –H

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

top –u uid -H

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

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

(28)

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

メモリの計測

小規模なジョブをdebug.qに投入する。

その際のジョブIDを記録する

ジョブ終了後、qreportコマンドで確認する(ジョブ終

了後、qreportで確認できるまで最大5分の時差がある)

$ qsub –l debug job01.sh

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

$ qreport -j 1905176|grep maxvmem maxvmem 2.1G

計測用のジョブは、可能な限り少ないデータで実施する

測定できた場合、データ量を増やしつつ複数回計測する

データ量の変化と消費メモリ量の相関を確認し、実際の処

(29)

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

I/Oの計測

ラッパーで計測する

open 開いたファイルの数 close 閉じたファイルの数 getattr ファイル属性の取得数 setattr ファイル属性の設定数 write_bytes 書き込み量(Bytes)

lustre_analyzer.rb “command arg1 arg2 …”

“command”で指定したコマンドが終了するまでにlustreに発生した各種

ファイル操作の回数・入出力量を計測する。計測内容は以下の表の通り。

同ホストで同じタイミングで他のプロセスがlustreにアクセスした場合、

その合算値が表示される

(30)

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

実行例

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

(31)

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

ラッパー実行時の注意

$ 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に投入して測定するという方法もある

(32)

目次

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

3.3 I/O負荷を軽減する

3.4 qsubオプションの検討

3.5 ジョブ実行時のお願い

(33)

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

I/O負荷は、単体ジョブテストで計測した

値に同時実行数を乗じる必要がある

1ジョブの負荷は僅かでも、100倍、

1,000倍では莫大な負荷になる

lustre lustre

(34)

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

前述の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

(35)

I/O負荷の許容値

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

この値は

「ファイルシステム全体での負荷の許容値」

であることに注意。

open

1秒あたりのopen総数

30,000で危険な状態

close

1秒あたりのclose総数

30,000で危険な状態

getattr

1秒あたりのgetattr総数

8,000で危険な状態

setattr

1秒あたりのsetattr総数

1,600で危険な状態

(36)

目次

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

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

3.4 qsubオプションの検討

3.5 ジョブ実行時のお願い

(37)

I/O負荷を軽減する1

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

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

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

※実装例1(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

※実装例2(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

(38)

I/O負荷を軽減する2

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

ファイルのopen, closeは比較的コストの高い処理であるため、

これだけ大きな差として現れる。

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); #ファイルハンドルを閉じる }

※実装例1(good)

※実装例2(bad)

「コストの高い処理」をループ内で実行していないか必ず

チェックする

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

(39)

I/O負荷を軽減する3

SSDの活用を検討する

“-l ssd”指定時に使用できる実行ホストには、

SSDがディレクトリ/ssdにマウントされている

/tmp, /lustre1,2と比較して高速にアクセスで

きる。容量は約350GB(実効容量)

計算ノード上のローカル領域であるため、ジョ

ブを実行したホストからのみ参照可能

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

中間ファイルを大量に作成する場合

入力ファイルが多数の小さいファイルである場合

(40)

I/O負荷を軽減する4

SSD使用時の約束事

ディレクトリ/ssd/ユーザID/を作成して、その中にファイル等

を配置する(例:/ssd/lect01/foo)

使用量の制限はないが、他ユーザとの同時使用の可能性も考慮

し、使用は100GB程度までに抑える

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

入れる

あくまで一時的なファイルを配置するために使うため、永続性

は保障されない。メンテナンス等でサーバを再起動した場合、

ファイルは削除される(※検討中)

最終アクセス時間から一定時間(month系キュー:1か月

week系キュー:2週間)経過した場合、ファイルは削除対象と

なる(※検討中)

(41)

同時実行数を制限する1

それでもI/O量が多い場合は、同時実行数を抑制する。

この方法が総I/O量を抑制する最も効果的な方法

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

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

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

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

※アレイジョブの場合

以下の指定では500のタスクが動作するが、

同時に進行するタスクは最大で100となる。

(42)

同時実行数を制限する2

$ qsub –N job1 job01.sh

$ qsub –N job2 –hold_jid job1 job02.sh

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

-N ジョブ名:

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

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

指定したジョブIDまたはジョブ名のジョブが終了するまで、今回投入

するジョブをhold状態にする。指定したジョブが終了すると、自動的

にhold状態は解除され、実行可能な状態となる。

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

※非アレイジョブの場合

一度にqsubする回数を抑える

ジョブに順序をつける

(43)

目次

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

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

3.3 I/O負荷を軽減する

(44)

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

(45)

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

実際のリソース要求が、使用対象ノードのメモリ量を

超過しないよう注意する。超過した場合、ジョブはサブミット

されても実行されない。

(46)

目次

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

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

3.3 I/O負荷を軽減する

3.4 qsubオプションの検討

3.5 ジョブ実行時のお願い

(47)

ジョブ実行時のお願い

負荷の計測およびdebug.qでの小規模のテストを

実施し、問題なく動作することを確認する。

確認できたら本番のキューに投入し、徐々に投入

数を増やしていく

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

(48)

目次

1.

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

2.

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

(49)

目次

(50)

実行状況を確認する1

ジョブの実行状況は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 (略)

(51)

実行状況を確認する2

LOADがNCPU(CPUコア数)を超過している

場合

→ ジョブが意図せずにマルチスレッドで動作

している可能性

→ MPIジョブでmachinefile指定をミスしてい

る可能性

SWAPUSがGB単位になっている場合

→ s_vmem, mem_req指定ミスの可能性

(52)

実行状況を確認する3

スパコンの負荷はDDBJのWebページ

「スパコン稼働状況」からも確認可能

http://sc.ddbj.nig.ac.jp/index.php/ja-nig-statistics

(53)

目次

(54)

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

大量のジョブを実行すると、正常に完了したか否か

の確認に手間がかかる。

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

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

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

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

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

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

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

実行中に問題が発生したジョブのリストを簡単に作成できる

再投入時の推奨オプションを得られる

(※ジョブを再投入する機能はない)

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

(55)

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

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

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

ext ジョブのexit statusコード。0以外は異常終了を示す fail UGEの終了コード。0以外は異常終了を示す clock 実行時間(ジョブ開始~終了までの所要時間) mmem 実際に使用した仮想メモリの最大値 Rq, Rm ジョブ再投入時に推奨されるキュー(ジョブ失敗時のみ表示) Rm ジョブ再投入時に推奨されるメモリ要求量(ジョブ失敗時のみ表示) Ropt ジョブ再投入時に推奨されるqsubオプション(ジョブ失敗時のみ表示)

(56)

問い合わせ先

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

下さい。

遺伝研スパコンSEチーム

Mail:

sc-info@nig.ac.jp

居室:w202

内線:9461

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

(57)

変更履歴

変更日付 変更内容

2012/05/10 新規作成

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

参照

関連したドキュメント

などに名を残す数学者であるが、「ガロア理論 (Galois theory)」の教科書を

ちな みに定理の名前は証明に貢献した数学者たち Martin Davis, Yuri Matiyasevich, Hilary Putnam, Julia Robinson の名字に由来する. この定理により Halt0 を

が前スライドの (i)-(iii) を満たすとする.このとき,以下の3つの公理を 満たす整数を に対する degree ( 次数 ) といい, と書く..

また、JR東日本パス (本券) を駅の指定席券売機に

を受けている保税蔵置場の名称及び所在地を、同法第 61 条の5第1項の承

72 Officeシリーズ Excel 2016 Learning(入門編) Excel の基本操作を覚える  ・Excel 2016 の最新機能を理解する  ・ブックの保存方法を習得する 73

地域の感染状況等に応じて、知事の判断により、 「入場をする者の 整理等」 「入場をする者に対するマスクの着用の周知」

備考 1.「処方」欄には、薬名、分量、用法及び用量を記載すること。