（様式 20）成果報告書

TSUBAME 共同利用 平成 27 年度 学術利用 成果報告書

利用課題名 Lustre における並列入出力の高速化に関する研究
英文：Study of High Performance Parallel I/O on a Lustre File System
堀 敦史
Atsushi Hori
国立研究開発法人 理化学研究所 計算科学研究機構
RIKEN AICS
URL
邦文抄録（300 字程度）
大規模データを扱う並列計算における集団型 MPI-IO の高速化は今後益々重要な課題になってきている。代表的な
MPI-IO 実装である ROMIO は様々な並列ファイルシステムをサポートしており、我々は ROMIO の実装内部の更なる高速化を図るために EARTH（Effective Aggregation Rounds with THrottling）と名付けた改変実装を提案している。本
課題では EARTH を TSUBAME2.5 上に実装し、Lustre への集団型 MPI-IO に関して HPIO ベンチマークによる評価を 64 ノードを用いて 768 プロセスにより行ったところ、EARTH による性能向上の効果が見られるケースもあった。
英文抄録（100 words 程度）
Improving collective MPI-IO performance is one of the key issues for high performance data intensivecomputing. ROMIO is a well-known MPI-IO implementation and it is available many kinds of parallel
file systems. We focus on further performance improvements of collective MPI-IO by implementing I/Orequest throttling scheme with stepwise data exchanges in our optimization framework named
EARTH (Effective Aggregation Rounds with Throttling). We have implemented the EARTH
optimization on the TSUBAME2.5 to examine its effectiveness on MPI-IO using Lustre. We have founda sort of improvements by the EARTH using 768 processes on 64 computing nodes.
Keywords: MPI-IO, ROMIO, two-phase I/O, aggregator, EARTH, throttling, stepwise data exchange

背景と目的
並列計算機の規模が増すにつれて並列計算により扱われるデータ量の増加が無視できなくなり、並列計算ロセス数増加に伴う並列ファイルシステムへの過剰なI/O 要求の発行とプロセス間データ通信のコスト増が挙げられる。

性能の向上におけるボトルネックの一つとなっている。

Lustre のような並列ファイルシステムでは、複数のス並列計算における標準的な通信インタフェースであるトレージデバイスを束ねて大容量・高スループットを備えMPI では、並列 I/O を含む I/O インタフェースとしてたファイルシステムを提供しており、クライアントからのMPI-IO が定められており、代表的な MPI-IO 実装としてI/O 要求がターゲットとなるストレージデバイスを管理す

ROMIO が広く利用されている。MPI-IO における集団る I/O サーバに送られて全体で高速な I/O を実現してい型 I/O 機能により並列ファイルシステムを用いて高速なる。しかしながら一度にたくさんの I/O 要求が発行される並列 I/O が利用できる。この中で ROMIO は Two-Phaseと、I/O サーバ側の処理能力を超えてしまい、I/O 処理がI/O（以下、TP-IO）と呼ばれる高速化実装が用いられて待たされるクライアントが出てくる。また I/O サーバ側も多いる。TP-IO は不連続なアクセスに対する集団型 I/O にくの I/O 要求を同時に処理するために高負荷の状態とおいて、I/O に関与するプロセス間で通信を行うことでアなり、またターゲットとなるストレージデバイスへの I/O 処

クセスパターンに合わせたデータレイアウトの並べ替え

理も混雑してしまう。その結果として I/O 性能の低下を招を行い、連続なデータレイアウトでファイルシステムに対いてしまう。

して I/O 操作を行うことで高速化を実現している。しかし

我 々 は 以 上 の 問 題 を 解 決 す る た め にながら、近年の計算機のノード数やノード内の CPU コア

EARTH(Effective Aggregation Rounds with Throttling)数の増加などに伴い、TP-IO による並列 I/O の性能がスと名付け た高 速化実 装を 提案し ている。 EARTH はケールしにくくなってきている。その大きな要因としてプROMIO における同時に発行するファイル I/O の数を（様式 20）成果報告書
Throttling 機構により制限することで、上記で述べた過（Effective Aggregation Rounds with THrottling）と名付

剰な I/O 要求による性能低下を回避し、かつ Throttling

けた ROMIO に対する最適化実装を提案しており、ファ機構に合わせた段階的なデータ通信を行うことで更なイルシステムへの I/O 要求の Throttling と、Throttling とる性能向上を狙っている。EARTH は既に京コンピュー連動して動作する段階的通信によって高速化を図るこ

タでの実装・評価を進めていたが、他の計算機システムとを目指している。

での有効性 を確認 する必 要があり 、そ の一環 とし てこれらの機能は京コンピュータでも実装と評価試験

TSUBAME2.5 を用いて InfiiniBand を用いた PC クラスを行っており、京での評価結果との比較検討を行うためタ環境での有効性を検証した。に、京とは異なる構成を持つ並列計算機システムとして、

概要

TSUBAME2.5 を利用して同様の評価を行うこととした。

メニーコア混在型並列計算機用基盤システムソフト

EARTH については、現在のところ論文執筆が完了してウェアの研究の一つとして、MPI-IO 実装である ROMIOいないため、実装方法について述べることを控えるが、における高速化を目指した最適化の実装と検証を進め

上記のメカニズムによって、(1)Throttling によりファイルている。特に集団型 I/O と呼ばれる入出力パターンにおシステムへの I/O 要求の数を制限して高い I/O スループ

ける最適化である TP-IO の実装に関して、Lustre のようットを狙い、さらに、(2)I/O 要求発行に対する Throttlingな並列ファイルシステムを用いた大規模環境向けに最に伴い、早く I/O 要求発行を終了するプロセスから順に適化された実装を目指している。集団型 MPI-IO による通信を開始できる段階的通信機構によって、一度に全Lustre への書込み処理における TP-IO 内部の処理の流プロセス間でデータ交換を行う際の通信混雑を避けるこれを図 1 に示す。この図では 4 プロセスが全て I/O 処理とによる通信時間の短縮を狙っている。

を行うアグリゲータとして機能している例を示しており，結果および考察

Lustre の各 Object Storage Target（OST）への書込みを実装した EARTH に対して HPIO ベンチマークによる行う前にデータの並べ替えを行った後に書き込みを行評価試験を行った。HPIO は不連続アクセスパターンにっている。このように TP-IO はデータ通信とファイル I/O対する集団型 MPI-IO の評価に用いられるベンチマーを組み合わせて高速化を図っている。一方で，近年のクで、今回は MPI_File_write_all の性能を 64 台の Thin

CPU のコア数増加やノード内に複数の CPU ソケットがノードを用いて 768 プロセスにより評価を行った。この評配置されていることに伴い、TP-IO においてアグリゲータ

価では各ノードに 12 プロセスずつ起動しており、ランクの数も多くなり，Lustre の各 OST や OST 群を管理する配置はノード毎に詰めてゆく形式を使った。一方、使用

Object Storage Server(OSS)への負荷が増加し、その結した Lustre の OST の個数は計算ノードと同じ 64 個とし果 I/O 性能が低下する問題がある。我々は EARTHた。またベンチマークではプロセス全体で約 137GB のファイルを生成するようにしており、7 回の I/O 性能計測

P0P1P2P3[0][0][0][1] [1][0] [1][1] [0][2] [0][3] [1][2] [1][3] [2][0] [2][1] [3][0] [3][1] [2][2] [2][3] [3][2] [3][3]値から最大値と最小値を除く値の平均値を記録した。
Lustre へ の ア ク セ ス で は ロ グ イ ン ノ ー ド 等 と 共 通 のInfiniBand ネットワークを経由することによる他のプログ

Aggregator #0(P0)

Aggregator #1(P1)

Aggregator #2(P2)Aggregator #3(P3)[0][0] [0][1] [2][0] [2][1][0][2] [0][3] [2][2] [2][3][1][0] [1][1] [3][0] [3][1][1][2] [1][3] [3][2] [3][3]

ラムからの外乱による影響や、Lustre への高負荷状態が続くことによる他の利用者への影響をできる限り小さくする必要があったために、一度に多くの評価を行わず、[0][0][0][1] [2][0] [2][1][0][2] [0][3] [2][2] [2][3][1][0] [1][1] [3][0] [3][1][1][2] [1][3] [3][2] [3][3]

日時を変えて評価を数回行い、その中の最大の平均値

OST #0OST #1

OST #2

OST #3を採取して比較検討を行った。この計測での I/O 性能値を図 2 に示す。この評価では Throttling の I/O リクエスト

図 1： 集団型 MPI-IO による書き込み処理における数を 2 個に設定して動かしており、EARTH(wr:2)は書込

TP-IO 内部の処理の流れの例

みでの Throttling のみで、EARTH(wr,ex:2)は書込みで（様式 20）成果報告書の Throttling に加え Throttling に合わせた段階的通信
np=768@64x12 (slot layout)orig）とアグリゲータ配置のみ最適化した実装（図中のagg_aw）での評価値も示している。この図で横軸はアグリゲータとなるプロセス数を示しており、256、384 および最大値である 768 プロセスの 3 点での性能値を示しているが、アグリゲータ数を増やしてゆく方が I/O 性能が高くなる傾向が見られた。

I/O throughput (MiB/s)を行っている。また比較のために現行 ROMIO（図中の
8000
7000
6000
5000
4000
3000
2000
1000
0128

I/O throughput (MiB/s)

np=768@64x12 (slot layout), req=2

EARTH(wr:1)
EARTH(wr:2)
EARTH(wr:4)

8000
7000
6000
5000
4000
3000
2000
1000
0256512# aggregators

1024

EARTH(wr,ex:1)
EARTH(wr,ex:2)
EARTH(wr,ex:4)

図 3： Throttling のリクエスト数を変えた際の I/O 性
能の変化
すれば性能向上に繋がる可能性があることが分かった
が、最適なリクエスト数を求める方法については今回の
128

256
512
# aggregators1024

評価試験のデータからは分からなかった。これは今後orig

agg_awの課題である。I/O のアクセスパターンやプロセス数、さEARTH(wr:2)

EARTH(wr,ex:2)

らにノード毎に配置されるプロセスの数など多数の要因

図 2： HPIO ベンチマークによる I/O 性能によって異なる振舞いをするものと思われるが、本研究とは別に京コンピュータでも同様の実装と評価試験を行また評価した 4 つのケースの中では、っているが、こちらでは通信時間とファイル I/O の時間かEARTH(wr,ex:2)が最も高い性能を示したが、アグリゲら、最適なリクエスト数を導きだせる可能性が見られるのータ配置のみ最適化した実装との差はアグリゲータ数で、同様のアプローチで行えないかなど、今後検証をが 768 の場合でも 12%程度とそれほど大きな性能向上進めてゆくことも検討する予定である。

は得られていない。これは TP-IO 内の主要な 3 つの処理の中で通信処理が大部分を占めているためで、まとめ、今後の課題

Throttling による書き込み性能の向上や段階的通信機

我々は EARTH と名付けた ROMIO における高速化実構で得られる性能向上の効果が相対的に小さくなって装を進めるにあたり、ファイル I/O 処理への Throttling 機いるためである。今回試験を行ったアクセスパターンは構の適用と、ファイル I/O に付随して行われるデータ通非常に通信コストが大きくなるものを意図的に選んでい信に対する段階的送受信機構を提案している。この実

るが、アクセスパターンによっては通信コストが低減して、装の有効性を検証するために、TSUBAME2.5 を利用さThrottling や段階的通信機構の有効性がもっと顕著にせて頂き、HPIO ベンチマークを用いた性能評価を行っなるケースもあるものと考えている。

た。その結果、Throttling および段階的送受信機構の有次に、Throttling のリクエスト数を変えて性能への影効性が見られる評価結果が得られたが、上記の 2 つの響を調査した。その結果を図 3 に示す。Throttling のリク最適化における最適な I/O 要求数の求め方など、まだエスト数を 1、2、4 と増やしてゆくと、Throttling と段階的分析が不十分な点が残っている。また本評価を行うにあ通信をリクエスト数が 2 で行った EARTH(wr,ex:2)のケーたり、ファイル I/O 対象の Lustre ファイルシステムに関しスで全プロセスがアグリゲータになった時が最も高い性て、ユーザがログイン時やノード間通信などに利用され能を出していることが分かる。最適なリクエスト数を設定るネットワーク上に繋がっているため、性能評価の実施

（様式 20）成果報告書
日時を変えながら、その中で得られた性能の平均値を求めることで、できる限り上記のような性能のばらつきを小さく抑える配慮を行いつつ評価した。その結果、64 ノードで 768 プロセスを起動した場合における Throttlingの効果を表すような評価結果が得られた。Throttling 機構での同時に発行する I/O リクエスト数の最適な値の算
出方法については、HPIO ベンチマーク等による Lustreへの大規模 I/O は高負荷な状態を招くので、他の利用者への影響等も配慮して長時間計測することは難しい状況であったため、評価に十分なデータを集めることが困難であった。よって今回は十分な検討が行えなかったが、これについては今後の課題として検討を続けてゆきたいと考えている。