関連情報
ホーム > 製品&サービス > コンサルティングサービス > HPCチューニングサービス > 事例一覧 > HECToRプロジェクト - チューニングレポート:HECToRへの統合気象予報システムOpenIFSの移植

HPCチューニングサービスの事例

チューニングレポート:HECToRへの統合気象予報システムOpenIFSの移植

Dr. Mark Richardson, Numerical Algorithms Group, Manchester
Dr. Grenville Lister, NCAS-CMS , University of Reading
Dr. Glenn Carver, ECMWF, Reading


[2016年3月掲載]

概要

統合気象予報システムIntegrated Forecasting System (IFS)ソフトウェアは現在、学術研究用途に関してOpenIFSとしてライセンスされています。しかし良好な性能を得るためには、ライブラリーの追加が必要となります。本レポートでは、HECToR Cray XE6で用いられるサポートライブラリー(GRIB_APIおよびFDB)の導入および検証を報告します。また、LUSTREファイルシステムにおけるファイルストライピング、OSページサイズ、出力に用いるMPIタスク数、およびFDBライブラリーのコンフィグパラメーターに関する調査結果を示します。

1.  イントロダクション

著名なソフトウェアである統合気象予報システムIntegrated Forecasting System (IFS)は、ヨーロッパ中期気象予報センター:European Centre for Medium-Range Weather Forecasts (ECMWF:www.ecmwf.int)により開発・運用されており、彼ら自身とその他の気象オフィスで中期気象予報目的に用いられています。OpenIFSは学術研究者向けに近年作成されたソフトウェアバージョンです。これは、気象とそれに関連するプロセスや、短期から季節範囲の気象予報、および予報の検証といった新規かつ重要な科学研究を可能にします。IFSモデルは、ECMWFにおいては並列I/Oシステムを用いて運用されています。こうしたシステムを用いない場合、アカデミック版のOpenIFSは、全てのI/Oはマスタータスクが行うことになり、HECToRでの実行は問題によっては大幅に制限されてしまいます。ここで、HECToRとは、90112コアを搭載するCray XE6システムで、Gemini内部ネットワークで結合した専有ノード上で計算は実行されます。

本プロジェクトは、このI/Oの問題に対して、ECMWFのI/Oソフトウェアの一部をHECToRへ実装することにより解決します。これにより、(i)OpenIFSモデルに並列I/O機能(FDB)を装備し、(ii)このモデルの出力を管理・操作するユーザーアプリケーションを提供します。本プロジェクトは、サポートライブラリーのインストールとその性能の採取に関するOpenIFSの利用方法を報告します。

Cray XE6におけるOpenIFS操作に関して、様々な提言をします。最適化チューニングでは、Lustreファイルストライピング・サイズやその数、hugepage設定、FDBコンフィグレーションを調査しました。本レポートは、本プロジェクトで行われた4つの作業項目の詳細を記述しています。その内容は次のものです:サポートライブラリーGRIB_APIおよびFDBのインストール(セクション2で示します)、FDBを用いたOpenIFSがFDBを用いない場合と同じ結果を算出することの確認(セクション3)、デフォルトにおけるシミュレーション性能の調査(セクション4)、シミュレーション性能向上のための幾つかのパラメーター調整(セクション5)。最後に推奨される操作/設定と結論を示します。

2.  サポートライブラリーの構築

2.1  前提とするソフトウェア

本プロジェクトではFDBの最新のバージョンを用います。FDBライブラリーはGRIB_APIおよびECKITライブラリーと依存関係を持ちます。このためこれらを先に構築しなくてはなりません。OpenIFSは、FDBが必要とするかどうかにか関わらずGRIB_APIともリンクされています。

HECToR上では、多くのユーザーが望む如何なるソフトウェアもインストール可能なパッケージアカウントが用意されています。OpenIFSに関するホームディレクトリーは、/home/y07/y07/oifsで、作業ディレクトリーは/work/y07/y07/oifsです。作業ディレクトリー/work/y07/y07/oifsの配下にはビルド結果がインストールされるディレクトリーが作成されます。ここで、ビルドされた如何なる構成にも、"prefix"は"install"ディレクトリを含みます。

ライブラリーに対して2つの実装が構築されました。これらはバージョンの更新時に分離してビルド・インストールするためのものです。この意図は、ライブラリーを構築するためにHECToRのデフォルト環境を使用することです。実際に、プロジェクト期間中にデフォルト値が変更され、最新(2013年10月)環境がCCE8.1.8となっています。

これら分離したビルドはGNUコンパイラーを用いて行いました。これにより、ポストプロセスやジョブ準備のような作業のためのシリアルキューで、GRIB_APIを用いることが出来ます。ただし、これらのライブラリーのターゲット・アーキテクチャーは、ログインノード(シリアルノード)の"Istanbul"ヘキサ・コアです。

2.2  ビルド方法

GRIB_APIや、FDBとECKITは時々更新の必要が生じる場合があります。これは通常ECMWFからの指示によるものです。この処理は典型的なソフトウェアのビルドです。最初にソースコードを更新して、makefileを作成します。GRIB_APIのmakefileはGNU autotoolを用いて作成します。コンフィグの詳細は付録Aを参照してください。ECKITとFDBのmakefileはCMAKEを用いて作成します。このコンフィグ処理では、ビルド環境の決定とコンパイルフラグの設定のために幾つかのコンパイルテストが行われます。このプロセスは、クロスコンパイル環境だったりログインノードで動かないプログラムがある場合には、ビルドがうまく行きません。そこで、FDBに対してはtoolchainファイルを作成し、こうしたテストをバイパスして、適切な設定をさせた後に正常終了するようにしました。構成時に、インストール先には計算ノードがアクセスできる場所を指定しました。これは、計算ノード上に構築する際にテストに用いるためです。

ビルド・インストールを完了した後に、3つのモジュールを作成しました。これを用いれば、OpenIFSのビルド時にライブラリーのCCSバージョンを容易に利用できるようになります。


    module load grib_api_cce   GRIB_API環境設定
    module load fdb_cce         FDB環境設定
    module load openifs_cce    OpenIFSセットアップとgrib_api、fdbの呼出し

モジュールファイルは、"oifs"アカウントのmodulesディレクトリーに置きます。ユーザーは、"module use ~oifs/modules"と指定してアクセスします。バージョン番号は最初に0.0.1から始まり、更新に合わせて最後の数字が繰り上がります。稼働バージョンは0.0.2で、これはopenifs_cceのgrib_api_cceおよびfdb_cceの正しいバージョンと連携しています。最新バージョンは0.0.3としてカプセル化されました。デフォルトを見るには"module avail openifs_cce"としてモジュール問合せをしてみることをお勧めします。

フロントエンドでのライブラリービルドのテストは、コンパイラーをGCCへ変更すること以外は直截的に行えます。計算ノードでは、ログインノードとは異なり、ジョブスケジューラーへの投入が必要です。計算ノードでライブラリーを用いるには、ジョブスクリプト内でのモジュールのロード指示が必要です。

2.3  可視化ツールMatView

ユーザーは計算結果の可視化の方法を用意しなくてはなりません。良く用いられるのはMatView[1]です。このソフトウェアはダウンロード後にビルドが必要です。しかしながら、HECToR上では多くの依存性を解決しなくてはならず、ビルドは困難な状況でした。この問題に対し、dCSEプロジェクトに追加のヘルプディスクが用意されて対応に当たりました。こうして、GUI機能はありませんがバッチ処理バージョンがディレクトリー~oifs配下にビルドされて利用可能になりました。ここでは、ECMWFから良いサポートを頂きました。

3.  FDBを用いたOpenIFSの検証

インストールがうまく行った事とFDBを用いたOpenIFSが動作することの確認のため、3つのテスト(T159,T511,T1279)を行いました。各テストケースにおいては、FDB不使用(LFDBOP=F[alse]、デフォルト)かFDB使用(LFDBOP=T[rue])かの選択が可能です。このモードは、ネームリストファイル内の指定で変更可能です。

OpenIFSのデフォルト動作では、出力ステップ毎にGRIBファイルが書出されます。指定された時間ステップ毎に2つのGRIBファイルが出力されます:一つはグリッド点データ、もう一つはスペクトルデータを含み、ファイル名は、例えば以下のように適宜つけられます:


    ICMGGfwj8+000024 for grid point data
    ICMSHfwj8+000036 for spectral data

この出力は、一回のシミュレーションで多くのファイルが生成されることから好ましくありません。さらに、これらのファイルは一つのマスタータスクで行われ、他のMPIタスクからデータを収集する処理が要求されます。幸いにこれらファイルは移植性の高い、標準的に用いられているものです。詳細は付録Bを参照してください。

FDBを用いる場合は、GRIBファイルは同じ形式ですが、ファイルの詳細な構造は異なりディレクトリー構造も変わります。この場合は、このケースのディレクトリーにGRIBファイルが時間ステップ毎に生成される代わりに、"fdb<RUNID>"という名のサブディレクトリーが作られ、さらにサブディレクトリーを、表1に示すシミュレーションの開始日時とテストタイプに因んだ名前で作成します。

Size in bytes File name
165953536 0000:fc:sfc.0.20131016.084031.7773890805760.dat
65536 0000:fc:sfc.0.20131016.084031.7773890805761.idx
267 0000:fc:sfc.0.20131016.084031.7773890805761.idx.files
165953536 0000:fc:sfc.0.20131019.164347.88669599825920.dat
表1:FDBを用いたテストT511でのサブ・サブディレクトリー内に生成される典型的なファイル

よって、非FDBとFDBの出力の比較は直截的にはいきません。しかしながら最終的に、ベースラインケースが計算されて、比較が実行されて、同じ結果を与えることが確認されました。これは、FDBファイルの内容が、GRIBによって異なる構造のデータを単純にOpenIFS出力へエンコードしただけのものであることから予想された結果でした。

3.1  ベースライン・テストケース

OpenIFSのソースコードをレディング大学のレポジトリーから入手し、新たなモジュールとサポートライブラリーを用いてビルドして、基本的なテストを行いました。IFSのビルドの詳細は付録Bを参照してください。性能最適化の最新の調査は、T1279の更新版T1279_opを用いて行なわれました。ビルド結果のバイナリーファイル(master.exe)は、標準スクリプト:ifs_run.shを用いて起動可能です。

OpenIFSの初期のバージョンは、スペクトルファイルとグリッドファイルの形式のGRIB形式ファイルのみを生成します。これらは、ユーザーが指定した各出力時間ステップで別々に書出されます。本プロジェクトで開発されたバージョンは、FDBファイル出力も可能です。

例えばT159テストケースの場合、7回の出力ステップで各2ファイルおよびログファイル一つの、計15ファイルを生成します。ざっくりとした比較ですが、結果のディレクトリー内のファイルサイズを合計して、FDBアーカイブデータ容量と比較しました。各ケースについて総バイト数は一致しました。さらに、GRIB APIツールにより個々のフィールドを抽出してFDB GRIBファイルを連結し、GRIBツールを用いてこれらフィールドを、同一の実行から得た非FDBのGRIB出力からのフィールドを比較したところ、その結果はビットレベルで一致したことを確認しました(ログインノード向けにビルドされたGRIBツールを用いました)。考察したすべてのケースは正確に一致しました。

表2は、実行ログファイルから採取した非FDBの3種(T1279_opは非FDBで実行していません)のテストケースで、ベースラインの値も載せました。

Case T159 T511 T1279 T1279_op
MPIxOMP 16x8 128x8 512x8 512x8
Total cores 128 1024 4096 4096
Non-FDB
Non-FDB file size
/time step
14MB+31MB (45MB) 133MB+248MB (481MB) 800MB+1.6GB (2.4GB) -
Directory size
at end of run
315MB 2.6GB 16GB -
Forecast days
/day non-FDB
3372 679 284 -
With-FDB
Directory size
at end of run
315MB 2.6GB 16GB 324GB
Baseline wall time
Minutes
5 9 17 26
Forecast days
/day with-FDB
3347 691 292 193
表2:各テストケースにおける非FDBとFDB間の結果ファイルサイズ比較

4番目のT1279_opは、OpenIFSへ変更があったプロジェクトの最後に設定したものです。この時、新しいOpenIFSバージョンに合わせるためにネームリストは変更されています。このテストケースは以下のように変更されました:ネームリスト変数NFPPHYは、最後のMFPPHY2つが不要のため、88から86へ減らしました。

3.2  スケール性能

初期のテストケースT1279をスケーリング性能の調査に用いました。


図1:テストケースT1279

図1は、4096MPIタスクに向かってMPIのみのスケール性能が落ちていく事を示しています。OpenMPによる加速は、この性能を理論スケール性能ラインへ近づけます。この要因の一つは、MPIタスク数の減少によるノードを跨ぐ通信の減少によるものです。

4  I/Oメトリック

3種のテストケースは、短いターンアラウンドタイムが重要なケースに役立ちます。一般には20分のキューで実行は収まり、待ち時間が問題になることはありません。Cray性能分析ツールを用いて、非FDBとFDBの出力の割合を調べました。非FDBは、出力ステップ(全ステップではない)毎に2ファイルを書出します。セクション3で述べたように、FDBモードでは出力毎に3ファイルが生成されます。各出力時に追加されるのはdatファイルです。出力を行うタスク数はセクション5.3で述べるように変更可能です。

4.1  ビルトインされたメトリック

性能を表す最も重要な指標/メトリックは、ウォールクロック[日]当たりの予報日数です。この値は、問題ケースサイズ、ケースの複雑性、使用するコア数など、様々な要因に影響されます。コア数は、NPROC(ネームリストファイル内で)とNTHREADSで決定され、NTHREADSは実行が開始される直前にOMP_NUM_THREADS環境変数に割り当てられます。


図2:テストケースT1279_opの、4096コア(512・MPIタスク×8・OMPスレッド)を用いた3日間のシミュレーションに対する、メトリック:ステップ当りの予報日数/日

プロジェクトの最後にECMWFの開発者により、各モデル時間ステップ毎の、平均、ピーク、瞬間予報日数/日が出力に追加されました。図2において、瞬間予報日数/日の周期的な凹みは、この時間ステップ内の(24時間毎の)周期的な追加の計算に起因します。

4.2   Cray性能分析ツール

Cray PATツールキットを用いた分析を行いました。最初の採取情報からコードのスケール性能に関する情報が得られました。図3,4は、2つの小規模ケースに対するコードのユーザーセクションのプロファイルを示しています。これらは非常によく似ており、良好なスケール性能が示唆されています。ECMWFの開発者からは、マスターループ17は取るに足らないもので、それほど目立って高コストなものでないとのことでした。しかしながらこれらの例は、短い実行時間の場合のものであり、初期化処理が支配的になっています。


図3:Cray PATによるテストT159のトレース情報の一部


図3:Cray PATによるテストT511のトレース情報の一部

Cray PATでファイルアクセスパターン情報も採取しました。この情報を展開するのに推奨されるやり方を以下に記します。ステップ4は実行形態により異なります。


PerftoolsモジュールはOpenIFSのビルド前にロードして置く。
  module load perftools
(1)実行形式を作成します。
  pat_build -O apa master.exe (ISSUE)
(2)オプションで編集したAPAファイルを用いることが出来ます。これを用いて再度実行形式を用意します。
  pat_build -O (apa file)
(3)master.exe+apaを実行します
(4) ioグループを追加するためにAPAファイルを編集します。
  -g sysio,stdio,ffio,aio,
  -g mpi
  -g omp

4.2.1   FDB無のOpenIFSに対するPATレポート

トレース実行後に、コマンドpat_reportを用いてトレース情報テキストファイルを生成します。このファイルには詳細な性能情報が含まれます。例として以下の抜粋表のような、ディスク書き込みのセクションも含まれます。

表3はその例で、テストT159のファイルカテゴリーGGとSHが示されています。書込み速度は、シミュレーションの最終段階の初期において、数MB/sから数百MB/sまで決まった特徴が無く様々です。同じ容量のファイルに対しても書き込み速度は異なります。

Write time
seconds
Write
MBytes
Write Rate
MBytes/sec
Writes Write Bytes
per call
File Name
27.281 30.28 1.110 77.0 412462.55 ./ICMSHfwj8+000048
5.452 30.28 5.555 77.0 412462.55 ./ICMSHfwj8+000000
3.790 13.82 3.647 41.0 353638.93 ICMGGfwj8+000024
2.904 30.28 10.427 77.0 412462.55 ./ICMSHfwj8+000036
2.753 30.28 10.998 77.0 412462.55 ./ICMSHfwj8+000024
2.071 30.28 14.620 77.0 412462.55 ./ICMSHfwj8+000060
0.110 13.82 124.739 41.0 353638.93 ICMGGfwj8+000036
0.100 13.82 137.674 41.0 353638.93 ICMGGfwj8+000072
0.091 30.28 330.962 77.0 412462.55 ./ICMSHfwj8+000012
0.068 11.17 162.368 41.0 285687.51 ICMGGfwj8+000000
0.062 30.28 484.929 77.0 412462.55 ./ICMSHfwj8+000072
0.048 13.82 286.339 41.0 353638.93 ICMGGfwj8+000060
0.047 13.82 289.694 41.0 353638.93 ICMGGfwj8+000048
0.041 13.82 336.466 41.0 353638.93 ICMGGfwj8+000012
表3:非FDBバージョンのT519テストにおけるファイル毎の出力性能情報

4.2.2   T159テストでのFDB版OpenIFSに対するPATレポート

FDB版に対して同様に出力レポートを採取しました。この場合も同じく、表4に示すように書込み速度は様々です。非FDB版との違いは、FDB版が出力タスク当たり1ファイルのみ書き込むことです。この実行はデフォルトのLustreファイルストライピング数=1およびストライピングサイズ=4で行いました。

Write
time
seconds
Write
MBytes
Write
Rate
MBytes/sec
Writes Write
Bytes
per call
File Name
0.103 19.89 191.99 812.0 25695.84 /:fc:sfc.8.20131018.112231.125937031053312.dat
0.099 18.06 181.97 756.0 25058.20 /:fc:sfc.14.20131018.112231.123394410414080.dat
0.091 20.76 220.45 826.0 26366.14 /:fc:sfc.4.20131018.112231.125464584650752.dat
0.070 20.87 295.07 840.0 26063.24 /:fc:sfc.3.20131018.112231.127242701111296.dat
0.067 19.89 296.78 812.0 25695.84 /:fc:sfc.7.20131018.112231.125477469552640.dat
0.060 20.99 347.69 840.0 26204.65 /:fc:sfc.1.20131018.112231.127234111176704.dat
0.054 19.26 353.77 784.0 25761.96 /:fc:sfc.10.20131018.112231.125945620987904.dat
0.053 19.07 357.10 798.0 25068.72 /:fc:sfc.9.20131018.112231.125941326020608.dat
0.052 18.13 347.52 756.0 25150.31 /:fc:sfc.13.20131018.112231.123390115446784.dat
表4:FDBバージョンのT519テストにおけるファイル毎の出力性能情報

FDBディレクトリー内のファイルは、ファイル名にメタデータを含むため、ディレクトリーを素早く見渡すことが困難で、実行毎に新たなdatファイルが生成されます。デフォルトでは、MPIタスク数に比例してdatファイルが生成されます。

5  デフォルト値の変更の調査

OpenIFSの性能調査のため、LUSTREファイルシステムパラメーター、仮想メモリーページおよびFDB出力モードといった、様々なパラメーターを調査しました。このセクションでは、これらのパラメーターを変化させた場合の影響を報告します。ページサイズはOpenIFSのビルド時に指定されますが、ここでは、ページサイズの変更方法とシミュレーション結果へ与えるその影響を示します。ベースラインの3種テストケースとして、4096バイトのデフォルトページサイズ、デフォルトLUSTREストライピング数4およびストライピングサイズ1MBを用いました。

5.1  LUSTREファイルシステム

LUSTRE®は、ハイパフォーマンス計算クラスター向けに設計された、高性能、高並列、POSIX互換のネットワークファイルシステムです(http://www.Lustre.org)。LUSTREファイルシステムは分散マルチノードに対する多重サービスを提供します。このファイルシステムは、Meta-Data Target(MDT)を構成し、ファイル所有権、タイムスタンプ、アクセス権等のディレクトリーとファイルのメタ情報と、ファイルデータを一つ以上のオブジェクトに保持する一連のObject Storage Targets(OST)を保管しています。

HECToR上においては、2つのLUSTREファイルシステムパーティションが用意されています。一つは一般ユーザー向けのデフォルトのストライピング数が1でストライピングサイズが1MBのものです。もう一つは、NERCユーザー向けの、デフォルトのストライピング数が4でストライピングサイズが1MBのものです。本プロジェクトはその性格上NERCパーティションを用いています。ここでは84のOSTを有します。

LUSTREの構成方法は数種あります:(i)ハードウェアに最適化した管理者設定、(ii)ユーザーによるストライピングパターン設定、(iii)ユーザーによるストライピングパターンのシミュレーションコードによる設定。本作業の多くは、インストール時のシステムハードウェアセットアップとして(ii)で行いましたが、(ii)で性能向上が見込めることが確定するまでは、APIの作業は保留されました。

一般利用でない様々な管理者コマンドが有りますが(mkfs.lustre,tunefs.lustre,mount.lustre,lctl)、個々のファイルに対してLustre固有の情報を操作するユーザーレベルのコマンドは、lctlです。このコマンドは、ディレクトリーに対するストライピング数やストライピングサイズを操作するオプション(サブコマンド)を用いて利用されます。事前のLustre設定を用いた空ファイルを作成可能ですが、既存のファイルに対するストライピング設定変更はできません。ディレクトリが既に構成されている場合は、その内容は同じストライピング設定を継承するので、プログラム内から作成された新しいファイルは、同じストライピング属性を獲得します。
コマンド、lfs setstripe -c 8 -s 16M <directory name> は、ディレクトリーに対し、ストライピング数が8で、ストライピングサイズが16MBと設定します。

本セクションの作業は、テストケースT1279_opを用いて、hugepageサイズを変化させてテストを行いました。特定のhugepageサイズ(2MB)におけるLustreパラメーターの変化によって、実行時間が如何に影響されるかを、図6,7で示しました。

5.1.1  ストライピング数の変化

ストライピング数のデフォルトは4です。サブコマンドsetstripeを実行直前に適用して、その後の新規ファイルに対して、この更新された属性を持つようにしました。


図6:テストT1279_opにおけるLFSストライピング数変化の影響

当アプリケーションにとってデフォルト設定は最適なものではありません。ストライピング数を増やした場合、および1に減らした場合に、性能は向上しています。更にこのグラフは、実行を繰り返した場合に性能が劣化する現象も示しています。

5.1.2  ストライピングサイズの変化

ストライピングサイズのデフォルトは1MBです。サブコマンドsetstripeを実行直前に適用して、属性を変更してテストをしました。ここで、二回目の実行が最初の実行よりも早くなるという奇妙な現象が生じていました。8MBストライピングサイズの実行性能は最初は最も低く、二回目の実行性能は最も高いものになりました。

これは、各MPIタスクが単一のファイルを用いるという一般的なアドバイスに従うときに、性能の小さな変化を達成することができることを示しています。こうした設定での実行時には、ストライピングサイズは如何なる差も生じません。これは本プロジェクトで用いたデフォルトのストライピング数が4であるからです。ユーザーはストライピングサイズを1にすることが好ましいです。


図7:テストT1279_opにおける512タスク/8スレッド実行時のLFSストライピングサイズの影響

5.2  Hugepageサイズの影響

Hugepageは、デフォルトのベースページサイズ4KBよりも大きな仮想メモリーページです。これは、大きなデータセット上の共通のアクセスパターンに対するメモリー性能を向上させます。また、プログラム内のデータ/テキストを高速ネットワークでアクセスすることにより、その最大サイズをより大きくすることが出来ます。その実行形式はHugepageを用いるライブラリーとリンクして可能になります。

モジュールファイルを通してアクセス可能な、hugepageクラスには6種あります。指定されたhugepageに応じて、モジュールファイルはその対応するリンクオプションと実行環境を設定します。この6種のモジュールは、hugepage128K,craype-hugepages512K, craype-hugepages2M, craype-hugepages8M, craype-hugepages16M, craype-hugepages64Mです。

Hugepageモジュールを用いてビルドした実行形式は、実行時にページサイズを変更可能です。OpenIFSでは2Mのhugepageが推奨されます。これは以下のようにビルドします:例えば、

module swap PrgEnv-pgi PrgEnv-cray
module load craype-hugepages2M
build

モジュールで設定された環境変数の内、2つは選択したページサイズによって異なります。これらを表5に示します。

Value for
HUGETLB_DEFAULT_PAGE_SIZE
Variable name
e.g. HUGETLB16M_POST_LINK_OPTS
(i.e. -Wl,--whole-archive,-lhugetlbfs,
lhugetlbfs,--no-whole-archive -Wl,
-Ttext-segment=0x20000000,
-zmax-pagesize=0x20000000 )
128K HUGETLB128K_POST_LINK_OPTS
512K HUGETLB512K_POST_LINK_OPTS
2M HUGETLB2M_POST_LINK_OPTS
8M HUGETLB8M_POST_LINK_OPTS
16M HUGETLB16M_POST_LINK_OPTS
32M HUGETLB32M_POST_LINK_OPTS
64M HUGETLBM_POST_LINK_OPTS
表5:hugepageにおけるコンパイル実行時の環境変数

ストライピング数4および8の2つのLustreストライピングケースに対して、様々なページサイズをテストしました。ストライピングサイズについては4MBのままとしました。図8は、run1-8ケースのみが、ページサイズの増加と共に、予報日数/日が単調増加するという現象が生じていることを示しています。


図8:ストライピング数4,8における、テストT1279_opにおける128ノード(512タスク/8スレッド)実行時のhugepageサイズの影響

結果として、それ以上のページサイズで性能利得が無いため、hugepageサイズには2MBが推奨されます。その他の組合せについては表6に示しています。

Lustre stripe
size
craype-
hugepages512K
craype-
hugepages2M
craype-
hugepages8M
craype-
hugepages16M
craype-
hugepages64M
1MB
2MB 6
4MB 2 1 3 4 5
8MB 7
16MB 8
64MB 9
表6:ストライピング数4の場合の推奨組合せ

5.3  出力タスク数の影響

FDBデータを出力するMPIタスク数は、全タスクのサブセットととして変更可能です。これらタスクは、ネームリストファイル(fort.4)内に設定された間隔を持つタスクIDのストライドを用いて選択されます。その変数NWRTOUTが、出力を担当するMPIタスクのストライド間隔になります。これはデフォルトで1となっており、全てのMPIタスクが出力をするようになっています。この値を変更すれば、同じノードに在る別のMPIタスクを、GRIB形式へのデータ・エンコード用に利用することが出来ます。

このエンコード処理は、同じノード上に在って出力を担当しない他のMPIタスク間でシェアさせることが可能です。例えば、ストライド間隔を1ノード上のMPIタスク数と同じにすれば、一つのノード上に一つの出力タスクを置くことが出来ます。これはノードからディスクへ書出されるデータストリームを制御します。残りのMPIタスクは、データをGRIB形式へエンコードして出力タスクをサポートします。しかしながら、データは通信が必要であり、その一つはエンコード処理で、残りは出力タスクへのデータ収集で生じる通信です。

Writer
stride
Number of
data
files
Typical
Size per
File
(GB)
Total size
files in
directory
(GB)
Case results written
to directory A
Case results written
to directory B
Wall
time
minutes
F/D
peak
F/D
(average)
Wall
time
minutes
F/D
peak
F/D
(average)
1 512 1.9
+0.5
218 16.0 216 198 14.3 233 221
2 256 2.2
+1.1
218 15.8 216 203 14.5 238 220
4 128 2.0 218 16.5 215 192 14.5 229 219
6 86 3.8 218 17.6 203 193 14.5 238 220
8 64 4.5 218 16.5 202 191 15.8 212 202
16 32 7.5
+7.1
218 20.1 173 153 19.5 188 160
表7:テストT1279_opを用いてFDB版について出力タスク数を減少させた場合の結果。+記号のものは、異なるサイズのファイルが存在する。

表7の値を図9でグラフ化しました。明らかにディレクトリーBには大きなバイアスがかかっており、これについてはより詳細な調査が必要です。


図9:様々なNWRTOUTに対する性能

全体として言えることは、出力タスク数の削減は、シミュレーション実行時間に関して有利になる影響をほとんど持たないということです。実際に多くの場合において実行時間は増加しています。予想していなかったのは、シミュレーション結果が異なるディレクトリーに書き出される場合に明らかな差がある事です。この事は、同じケースを同時に別のディレクトリー内で異なるストライドを持たせて実行した場合にも生じます。これは、その実行条件を別のディレクトリーへ切り替えた場合の結果と矛盾しないものでした。

4より大きなストライドの場合、ノード当たりのMPIタスクは4で、OpenMPスレッド数は8としているため、出力タスクは別のノードに置かれることになります。ストライド6をテストしたのは、それが85.6(実際には85)個の出力タスク数となり、OST数84に近い値を持つからです。ディレクトリーAの結果は、4と6の間に明らかな差を示していますが、これは出力タスクを持たない、つまり多くのエンコード作業が1ノード上の共有コアで発生しているノードの存在に由来するものでしょう。

5.4  FDBパラメーターの影響

FDBライブラリーがインストールされた以下のファイルを用いて、実行時パラメーターを調整することが出来ます。

      $FDB_HOME/etc/config/fdb/fdbRules

このファイルは、表8に示した、FDBの振る舞いを制御する4種の設定が含まれています。

Parameter Value on
HECToR
Options remarks
fdbAsyncWrite False 非同期出力を可能にする
fdbNbAsyncBuffers 4, 非同期ioバッファ数
fdbSizeAsyncBuffer (64*1024*1024),
非同期ioバッファのバイト数
doubleBuffer 0 データ転送にサイクリックバッファを使用
bufferSize 67108864(64*1024*1024)
doubleBufferSize 524288(0.5*1024*1024)
doubleBufferCount 20
blockSize -1 既存のファイルシステムのブロックサイズに
合わせるようにインデックスアクセスに関して
パディング・フィールドを追加する
syncDirOnFileFlush True ファイルをフラッシュする際にディレクトリーも
フラッシュする
表8:FDBルールファイルのコンフィグレーション・パラメーター

6  まとめ

Cray XE6上へのサポートライブラリーのビルドおよびインストールが完了しました。これらは2種のコンパイル環境でビルドされています:一つはCray compiler environment(CCE)、もう一つはGNUコンパイラーです。OpenIFSはこのFDBライブラリーをリンクしてビルドされました。これを用いて、これまでのGRIBシリアル出力ファイルの結果と同等な出力を確認しました。これは、同じデータをエンコードした同じGRIB形式を用いていることから期待された結果です。

4種のテストケースに対して、予報日数/日を指標に用いて、FDB版の性能測定を行いました。
LUSTREファイルシステムのパラメーターによる差は、多重実行時の変動に比較してそれほど大きな違いはないものでした。実行時間はそのディレクトリーの選択によっても変動しました。LUSTREパラメーターが性能に影響を与えない理由は、並列I/Oを用いるFDBの並列性が、ファイルの並列出力に相当するMPI-IOの呼出しでなく、データストリームの並列によるものであるためです。IOデータストリーム数がOST数と同程度であれば、性能向上はほとんどありません。この場合、ストライピングはOSTへの負荷を増やし、競合を生じる可能性が高いです。

ノード当たり一つの出力タスクを用いる事が推奨されます。ただしこの場合はGRIBへのエンコードにおいてノード内通信が発生します。

Hugepageが調査され、2MBページを用いる場合に僅かな改善が観察されました。OpenIFSのコンフィグでは、hugepages2Mモジュールと、4MBサイズのストライピングでディレクトリーを用いる事が推奨されます。

本作業は、IBM以外のシステムへの初めての移植となります。また、異機種のCMake(クロスコンパイル)の使用へも拡張されました。開発元マシンはGFSを用いており、LUSTREファイルシステムの振る舞いに関する知識は大変有益なものでした。コード内の出力タスクの削減に関するセクションは、休止状態になっていましたが、本作業により再稼働しました。

参考

[1] Metview 4 Wiki https://software.ecmwf.int/wiki/display/METV/Metview
[2]付録については原文書を参照してください。
Results matter. Trust NAG.

Privacy Policy | Trademarks