ファイルシステム利用技術 WG 成果報告書「ファイル I/O の分析と改善」(WG 活動期間:2012 年 9 月-2015 年 2 月)

2015 年 5 月 22 日
サイエンティフィック・システム研究会
ファイルシステム利用技術 WG

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

目 次
1 はじめに(WG 活動概要) ······································································ 1
1.1 WG 発足の背景 ············································································· 1
1.2 活動方針 ·················································································· 1
1.3 活動内容 ·················································································· 1
1.4 活動期間 ·················································································· 2
1.5 WG メンバー ··············································································· 2
1.6 活動実績 ·················································································· 22 ファイルシステムの利用における現状と課題 ·················································· 4
2.1 ファイルシステムの利用動向 ································································ 42.1.1 ローカルファイルシステム ······························································ 4
2.1.2 ネットワークファイルシステム ·························································· 5
2.1.3 並列分散ファイルシステム ······························································ 5
2.2 I/O 効率の改善に向けた方策について ························································ 6
2.3 I/O 効率の改善方法（ユーザに改善の機会を気付いてもらうための方法）························· 62.3.1 ステップ 1：I/O 比率の簡易確認 ························································· 82.3.2 ステップ 2：想定 I/O 量,想定 I/O 性能,システム負荷の確認································ 122.3.2.1 想定 I/O 量の確認 ································································· 122.3.2.2 想定 I/O 性能の確認 ······························································· 17
2.3.2.3 システム負荷の確認 ······························································· 20
2.3.3 ステップ 3：システムコール分析 ······················································· 22
2.3.4 ステップ 4：システム管理者による詳細分析·············································· 23
2.4 将来的に採取したい項目について ··························································· 23
3 分析ツール ··············································································· 25
3.1 背景 ····················································································· 25
3.2 目的 ····················································································· 26
3.3 ユーザレベルでの分析ツールの作成 ························································· 26
3.3.1 システムコール分析ツール「IO-Dock」の紹介 ············································ 26
3.4 システム管理者レベルでの分析ツールの検討 ················································· 31
3.4.1 I/O Accounting 情報の利用 ···························································· 31
3.4.2 ジョブ統計情報の利用(fefsvr) ························································· 32
3.5 まとめ ··················································································· 34
4 分析ツールによる解析事例 ································································· 35
4.1 宇宙航空研究開発機構 ····································································· 35
4.1.1 概要 ················································································· 35
4.1.1.1 システム概要····································································· 35
4.1.1.2 システム健康診断結果概要 ························································· 36
4.1.2 システムコール分析結果 ······························································· 38
4.1.2.1 実行環境········································································· 38
4.1.2.2 実行プログラム概要 ······························································· 38
4.1.2.3 分析結果········································································· 38
4.1.3 考察 ················································································· 41
4.1.4 まとめ ··············································································· 41iサイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.2 京都大学人文科学研究所附属東アジア人文情報学研究センター ································· 42
4.2.1 概要 ················································································· 42
4.2.1.1 システム概要····································································· 42
4.2.2 システムコール分析結果 ······························································· 42
4.2.2.1 実行環境········································································· 42
4.2.2.2 実行プログラム概要 ······························································· 42
4.2.2.3 分析結果 (2013 年 7 月 4 日) ······················································· 42
4.2.2.4 再分析結果 (2014 年 4 月 15 日) ···················································· 44
4.2.2.5 再々分析結果 (2014 年 9 月 5 日) ··················································· 45
4.2.3 考察 ················································································· 46
4.2.4 まとめ ··············································································· 46
4.3 国立天文台天文データセンター ····························································· 47
4.3.1 概要 ················································································· 47
4.3.1.1 システム概要····································································· 47
4.3.1.2 システム健康診断結果概要 ························································· 48
4.3.2 システムコール分析結果 ······························································· 48
4.3.2.1 実行環境········································································· 48
4.3.2.2 実行プログラム概要 ······························································· 49
4.3.2.3 分析結果········································································· 50
4.3.3 考察 ················································································· 56
4.3.4 まとめ ··············································································· 57
4.4 東京大学宇宙線研究所附属神岡宇宙素粒子研究施設 ··········································· 58
4.4.1 概要 ················································································· 58
4.4.1.1 システム概要····································································· 58
4.4.1.2 システム健康診断結果概要 ························································· 59
4.4.2 システムコール分析結果 ······························································· 59
4.4.2.1 実行環境········································································· 59
4.4.2.2 実行プログラム概要 ······························································· 60
4.4.2.3 分析結果········································································· 60
4.4.3 考察 ················································································· 62
4.4.4 まとめ ··············································································· 62
4.5 理化学研究所 ············································································· 63
4.5.1 概要 ················································································· 63
4.5.1.1 システム概要····································································· 63
4.5.1.2 システム健康診断結果概要 ························································· 64
4.5.2 システムコール分析結果 ······························································· 65
4.5.2.1 実行環境········································································· 65
4.5.2.2 実行プログラム概要 ······························································· 65
4.5.2.3 分析結果········································································· 66
4.5.3 考察 ················································································· 67
4.5.4 まとめ ··············································································· 67

5 今後に向けての提言 ······································································· 68
付 録 ····················································································· 69
資料 1 ストレージ技術動向 (2013 年 1 月時点) ·················································· 70
資料 2 モニタリング技術紹介 (2013 年 1 月時点) ················································ 73
資料 3 システムコール分析ツール「IO-Dock」使用手引書········································· 76
参考文献 ··················································································· 85

iiサイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

商標、登録商標について




















PRIMEHPC、PRIMERGY、ETERNUS、FEFS は、富士通株式会社の登録商標です。
すべての SPARC 商標は、SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における商標または登録商標です。
Intel、Intel Core、Xeon は、米国およびその他の国における Intel Corporation の商標または登録商標です。
Solaris、ZFS は、Oracle Corporation およびその子会社、関連会社の米国およびその他の国における商標
または登録商標です。
UNIX は、米国およびその他の国におけるオープン・グループの登録商標です。
Linux は、米国およびその他の国における Linus Torvalds 氏の登録商標です。
Red Hat、Red Hat Enterprise Linux は、Red Hat, Inc.の登録商標です。
CentOS は、CentOS ltd の商標または登録商標です。
XFS は、Silicon Graphics, Inc.の登録商標です。
GPFS は、International Business Machines Corporation の商標です。
Ethernet は、富士ゼロックス株式会社の登録商標です。
InfiniBand は、InfiniBand Trade Association の商標またはサービスマークです。
LTO、Ultrium は、Hewlett-Packard Company、International Business Machines Corporation、および Quantumの登録商標です。
NetApp は、米国および他の国における NetApp, Inc.の登録商標です。
MegaRAID は、LSI Corporation の商標または登録商標です。
Mellanox は、メラノックステクノロジーズ社の登録商標です。
SPECおよびベンチマーク名のSPEC SFS は、
米国およびその他の国におけるStandard Performance Evaluation
Corporation(SPEC)の商標または登録商標です。
その他一般に、会社名、機関名、製品名は各社、各機関の商標または登録商標です。
会社名、システム名、製品名等には必ずしも商標表示（TM・(R)）を付記しておりません。

iii

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

1 はじめに(WG 活動概要)
1.1 WG 発足の背景
SS 研では、データ管理が計算機システムの運用や利用において重要な要素であるという認識のもと、ストレージに関する広範な技術動向と課題を様々な視点から検討し、会員システムの構築・運用・利用に活用するために、「ネットワーク時代の統合ストレージマネージメント WG」(活動期間：2001 年 5 月～2003 年 4 月)、「ストレージを中心としたシステムマネージメント WG」 (活動期間：2003 年 5 月～2005 年 4 月)、「データマネジメントを意識したストレージソリューション WG」(活動期間：2006 年 2 月～2008 年 4 月)を発足させ議論してきた。また、2009 年 1 月から 2011 年 3 月には、HPC 分野でのデータ大規模化や計算機の高性能化の一層の促進に伴う今後のシステム検討における大規模ストレージのますますの重要性を意識し、大規模ストレージを有する各会員関係者の参加のもと、「大規模ストレージ WG」(活動期間：2009 年 1 月～2011 年 3 月)の場で、大規模ストレージが抱える技術課題と解決策について議論してきた。
「大規模ストレージ WG」は、文字通り大規模なストレージシステムを対象として議論を開始したが、「ファイ
ルシステム健康診断ツール」をはじめとするその成果の活用先は、これに留まらず幅広いシステムに適用できるものになったと考えている。同時に、今後計算機システム性能を最大限に引き出すためには、ストレージシステ
ムがより一層重要な役割を果たすことになることを再認識した一方で、ユーザ視点でのストレージシステムの利用技術に関する議論が不足しているという課題も明らかになってきた。
そこで、ストレージシステム利用における課題をユーザの視点から議論し、ユーザにストレージシステムの性能を意識していただくとともに、性能改善の手掛かりを提示できるような議論をする「ファイルシステム利用技
術 WG」を発足することとなった。

1.2 活動方針
観測機器や計測機器の高精度化、および計算機処理性能の飛躍的な向上に伴い、ユーザアプリケーションを用いた解析により更なる高度な研究活動が推進されている。ユーザアプリケーションの実行においては、計算機間で共有されたファイルシステムの利用が主流であり、格納された入出力データをより高速に、より効率的に活用することが求められている。
現在、大規模HPCシステムではファイルシステムが多様化し、システム全体として効率的に運用するためには、
ユーザアプリケーションやファイルシステムの入出力特性を最適化することが必要であり、明確なファイルシス
テムの利用技術の確立が急務となっている。
更に、現状、ユーザ側においてアプリケーションの入出力パターンを調査する手順やツールについては標準化されておらず、ファイルシステムの性能を効率的に発揮するための改善のための方策も求められている。
このような状況を踏まえ、既存システムの運用や次期システムの検討において、ユーザアプリケーションやファイルシステムの入出力特性を把握し、問題点を発見することで、プログラミングの改善方策や、システム利用の最適化方策を明確化することを本WGの活動テーマとする。

1.3 活動内容
1年目は、ストレージの技術動向[1]やモニタリング技術[2]の情報共有を行うと共に、会員各機関のアプリケーシ
ョン性能をモニタリングすることにより、各ファイルシステム上におけるアプリケーションのI/O特性の把握と、I/O性能チューニングに向けた必要情報の意見収集と検討を行った。
2年目以降は、採取した情報を用いて、アプリケーションの性能向上を図るために必要なモニタリング方法の検討や、「大規模ストレージWG」で作成した「ファイルシステム健康診断ツール」によるファイルシステムのI/O
特性の把握を行い、個別アプリケーションの挙動とファイルシステムの関連性について議論した。
こうした議論を重ねる過程で、ユーザアプリケーションやファイルシステムのI/O特性を把握し、最適化するための手法が確立されておらず、さらにユーザ自身が問題点を認識し、改善をするためのデータ項目が明確化され[1][2]

資料 1「ストレージ技術動向」を参照
資料 2「モニタリング技術紹介」を参照
1

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書ていないという実態が見えてきた。
そこで、I/O特性を把握し改善するための指針検討に加え、ユーザにとって真に有益となる情報と将来的に採取すべきデータ項目についての検討を行い、整理した上で最終成果物としてまとめることとした。

1.4 活動期間
2012年9月～2015年2月

1.5 WG メンバー
氏名
松澤 照男
担当幹事

機関/所属(2015 年 2 月 28 日現在)
北陸先端科学技術大学院大学(2012 年 9 月～2014 年 5 月)

井口寧

北陸先端科学技術大学院大学会員(2014 年 5 月～2015 年 2 月)

賛助会員（富士通）

藤田 直行（まとめ役） 宇宙航空研究開発機構
安岡 孝一
京都大学人文科学研究所附属東アジア人文情報学研究センター
松本 好美
高エネルギー加速器研究機構計算科学センター
推進委員
八木 雅文
国立天文台
早戸 良成
東京大学宇宙線研究所附属神岡宇宙素粒子研究施設
黒川 原佳
理化学研究所栄元 雅彦（まとめ役） 富士通(株) テクニカルコンピューティング・ソリューション事業本部
甲斐 俊彦
富士通(株) 次世代テクニカルコンピューティング開発本部
推進委員
酒井憲一郎
富士通(株) 次世代テクニカルコンピューティング開発本部宮本 巧輝
富士通(株) 次世代テクニカルコンピューティング開発本部阿部 孝之
富士通(株) テクニカルコンピューティング・ソリューション事業本部
富士通(株) テクニカルコンピューティング・ソリューション事業本部
オブザーバ 坂口 吉生
塚原 知宏
富士通(株) テクニカルコンピューティング・ソリューション事業本部

1.6 活動実績■第1回会合 : 2012年10月2日(火) 富士通(株)本社 出席者：会員=7名/富士通=11名
・WG発足の主旨確認
・活動内容検討- 活動の進め方検討- ファイルシステム利用上の課題抽出- 性能モニタリングについての検討- 成果物の意識共有■第2回会合 : 2013年1月11日(金) 富士通(株)北陸支社 出席者：会員=7名/富士通=10名
・富士通からの情報提供- ストレージの技術動向と製品紹介[荒木純隆(富士通)]- モニタリング技術紹介[宮本委員]■第3回会合 : 2013年4月23日(火) 富士通(株)本社 出席者：会員=6名/富士通=11名
・FEFSによる問題解決事例紹介[宮本委員]
・会員各機関からの情報提供（システム構成、現状の課題・要望）[藤田委員、安岡委員、松本委員、八木委員、早戸委員、黒川委員]
・会員各機関でのデータ採取項目の決定2

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書■第4回会合 : 2013年7月30日(火) 富士通(株)本社 出席者：会員=7名/富士通=10名
・2年目の活動計画について[藤田委員]
・アプリケーション特性の解析報告（JAXA、京大人文研、高エネ研、国立天文台、東大宇宙線研）[酒井委員］
・解析結果を踏まえたアプリケーション特性評価についての討議■第5回会合 : 2013年10月16日(水) 富士通(株)本社 出席者：会員=6名/富士通=9名
・「健康診断ツール」解析結果報告（東大宇宙線研、高エネ研、国立天文台）[甲斐委員]・システムコール分析事例（理研、JAXA）の結果報告[酒井委員］
・アプリケーションのチューニング指針の検討■第6回会合 : 2014年2月28日(金) 富士通(株)北陸支社 出席者：会員=8名/富士通=8名・システムコール分析事例 (JAXA、国立天文台)の結果報告 [宮本委員］
・会員機関におけるファイルシステムのトラブル事例報告[黒川委員、藤田委員]
・「システムコール解析ツール」の今後の展開予定[甲斐委員]
・将来的に採取したいデータ項目の議論■第7回会合 : 2014年5月29日(木) 富士通(株)本社 出席者：会員=6名/富士通=8名・システムコール分析・追加事例紹介（京大人文研プログラム改善後）[酒井委員]
・「システムコール解析ツール」プロトタイプ仕様紹介 [酒井委員]
・ユーザにI/O改善の機会を気づいてもらうための方法の検討
・将来的に採取したいデータ項目の整理
・成果報告書の目次検討、執筆分担決め■第8回会合 : 2014年8月27日(水) 富士通(株)本社 出席者：会員=6名/富士通=8名
・ユーザにI/O改善の機会を気づいてもらうための方法：ステップ別実施事項・確認ポイントの討議(第1回)
・成果報告書原稿のレビュー
・「システムコール解析ツール」の名称決定■第9回会合 : 2014年12月4日(木) 富士通(株)本社 出席者：会員=6名/富士通=8名
・ユーザにI/O改善の機会を気づいてもらうための方法：ステップ別実施事項・確認ポイントの討議(第2回)
・成果報告書暫定版レビュー(第1回)■第10回会合 : 2015年1月23日(金) 富士通(株)北陸支社 出席者：会員=7名/富士通=9名
・ユーザにI/O改善の機会を気づいてもらうための方法：ステップ別実施事項・確認ポイントまとめ
・成果報告書暫定版レビュー(第2回)■第11回会合 : 2015年2月23日(月) 富士通(株)本社 出席者：会員=5名/富士通=7名
・成果報告書最終レビュー
・成果報告会の検討

3

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

2 ファイルシステムの利用における現状と課題
ストレージシステムはサーバ、ストレージおよび、ファイルシステムによって構成されており、それぞれの組
み合わせによって特性が変わる。ユーザ視点においてユーザのアプリケーションやファイルシステムへの入出力特性を改善することは、単にアプリケーションの実行時間を短縮するだけでなく、システム全体として効率的な運用にも効果があることが本 WG での議論の中でわかってきた。しかし、現状ではユーザに対してアプリケーショ
ンの I/O 特性を明確化する手法が標準化されておらず、改善するための方法が明確化されていないという課題が浮き彫りになってきた。
そのため、本節ではユーザに I/O 効率の改善(I/O 特性チューニング)の機会に気付いてもらうために有益となる情報と採取すべき項目について整理し、ユーザのアプリケーションを高速に実行するためにプログラム改良の余地を判断する目安となる方策について説明する。

2.1 ファイルシステムの利用動向
ファイルシステムは、ストレージを管理するための機能が求められており、利用用途や各サイト(センタ)の運用設計やポリシーによって異なっている。以下に代表的なファイルシステム構成について説明する。

2.1.1 ローカルファイルシステム(1)ローカルファイルシステム
1 台の計算サーバ兼ファイルサーバに対してストレージが接続された構成である。
構成を図2.1 左側に示す。
計算サーバ内においてストレージを占有して利用するシンプルな構成であるため広く利用されている。
ただし、ストレージの容量に応じてファイルシステム容量が制限される、計算サーバ兼ファイルサーバが 1台のために性能が制限される、複数の計算サーバでファイル共有は行えない、などの制限がある。代表的なファイルシステムは xfs、ext4、zfs、などである。
(2)直接共有型ローカルファイルシステム
複数台の計算サーバ兼ファイルサーバに対して複数のストレージが FibreChannel などで接続された構成(直接共有型ローカルファイルシステム)である。構成を図 2.1 右側に示す。複数の計算サーバ内でファイル共有が可能であり、比較的シンプルな構成であるため広く利用されている。ただし、計算サーバとのファイル共有において高速にアクセスできる台数には上限がある。代表的なファイルシステムには QFS、Fujitsu 製 GFS がある。

図 2.1 ローカルファイルシステムと直接共有型ローカルファイルシステムの概要

4

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

2.1.2 ネットワークファイルシステム
計算サーバがネットワークを経由して直接共有型やローカルファイルシステムにアクセスする機構を実現する。
構成を図 2.2 に示す。多くの計算サーバに対してファイル共有が可能であり、設定が簡単であるなどの利便性が高いため、ファイルサーバの一般的な構成として広く利用されている。ただし、多くの計算サーバに対するファイル共有において高速にアクセスできる台数には上限がある。
代表的なファイルシステムには CIFS、NFS がある。

図 2.2 ネットワークファイルシステム

2.1.3 並列分散ファイルシステム
超並列で構成される計算機サーバに対し、複数のファイルサーバにファイルシステムの機能を分散させ 1 つのファイルサーバとしてファイル共有を実現する。構成を図 2.3 に示す。並列分散ファイルシステムでは高速大容量なファイルシステムを提供できるため、超並列計算システムでは主流のファイルシステムである。ただし、構成が複雑なために小規模なシステムには向いていない。代表的なファイルシステムには Lustre,富士通製 FEFS
(Lustre ベース),GPFS がある。

図 2.3 並列分散ファイルシステム

5

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

2.2 I/O 効率の改善に向けた方策について
システム全体を I/O 効率の観点から改善するためには、大別すると以下の 2 つの視点が考えられる。

(1) システム管理者視点
システムに主眼をおいてI/O効率を改善する方策が求められる。
システム更新,システム変更,新規調達を通じ、システム管理者がアプリケーション実行や運用データからシステム構成などを改善する。
なお、改善に際しては、
あらかじめシステムのボトルネックや性能劣化の原因を正しく特定しておく必要がある。また、活用できる技術
や機能はシステム更新やシステム調達の時期などに依存する。
(2) ユーザ視点
アプリケーションや業務の I/O 特性に主眼をおいて I/O 効率を改善する方策が求められる。アプリケーション
からの I/O 特性を調査し、どのような I/O 長で、どの程度アクセスしているかを確認する。
さらに、アプリケーションにおいて I/O(read,write など)の割合を調査し、ファイルシステムに適した I/O 特性にアプリケーションを変更することにより、システムの能力を最大限に活用し、アプリケーションにおける I/O
性能を改善することが可能となる。
ただし、ファイルシステムの性能とアプリケーションの I/O 特性を正しく検証するためには、ファイルシステ
ムなどの I/O に関する専門的なスキルが必要となることや長期間の調査が必要であることが課題である。
本WG では前述の2 つの視点のうち現在も手法や指針が明確化されていないユーザ視点におけるI/O 効率の改善に向けた方策について主として議論や検討を行った。
次節において 2 つの視点を意識し、I/O 効率の改善方法を 4 つのステップに整理した。

2.3 I/O 効率の改善方法（ユーザに改善の機会を気付いてもらうための方法）
アプリケーションを中心とした I/O 効率の改善（I/O 特性チューニング）に向けた情報の採取と判断について、ユーザが高いスキルを必要とせずに I/O 特性を簡単に把握し、改善を行えるように 4 つのステップに整理した。
各ステップの概要を以下に示す。
・ステップ 1 I/O 比率の簡易確認
・ステップ 2 想定 I/O 量,想定 I/O 性能,システム負荷の確認
・ステップ 3 システムコール分析
・ステップ 4 システム管理者による詳細分析
各ステップへの整理に際し、想定したジョブの種類、ジョブの実行方法および、ファイルシステムの種類を表2.1 に示す。
ジョブの種類については逐次ジョブと並列ジョブとする。
ジョブはアプリケーションやプログラムだけでなく、それを実行させるために必要な環境(シェルスクリプトや環境変数)も含める。
ジョブの実行方法については会話型処理（インタラクティブ実行と呼称）とジョブスケジューラを介した実行(バッチ実行と呼称)とする。計算サーバとジョブの関係は、計算サーバにユーザのジョブ 1 個が占有して実行されるものとする。
利用できるファイルシステムの種類についてはローカルファイルシステム(L-FS と呼称)、ネットワークファイ
システム(N-FS と呼称)および、並列分散ファイルシステム(P-FS と呼称)の 3 種類とする。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.1 想定対象
逐次ジョブ,並列ジョブ
インタラクティブ実行,バッチ実行
L-FS,N-FS,P-FS

6サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

逐次ジョブと並列ジョブの違いを図 2.4 に示す。
逐次ジョブは、1 つのプロセスによってアプリケーション(プログラム)が動作し、1 つのプロセッサ（コア）を利用して実行するジョブと定義する。
並列ジョブは、複数のプロセスによってアプリケーション(プログラム)が動作し、複数のプロセッサ（コア）を 1 台の計算サーバまたは複数の計算サーバを利用して実行するジョブと定義する。

図 2.4 逐次ジョブと並列ジョブ【今回情報採取やジョブ実行に利用したシステム環境】
今回情報採取に利用したシステム環境について以下に説明する。
[インタラクティブ実行の環境]
ハードウェアオペレーティングシステム
言語
L-FS
N-FS
P-FS
[バッチ実行の環境]
ハードウェアジョブスケジューラ
言語
P-FS： PRIMERGY RX200S8、 ETERNUS DX80、Mellanox SX6036、など： RedHat 6.5： gcc version 4.4.7 20120313、 OpenMPI 1.4.5： ext4： NFS V3
： FEFS V10L30： PRIMEHPC FX100、NetApp E5560、Mellanox SX6036、など： Technical Computing Suite のジョブ運用ソフトウェア： Technical Computing Suite の Technocal Computing
Language： Technical Computing Suite の FEFS V10L30【各ステップにおける説明内容】
各ステップでは、以下の 5 つの項目について説明する。
1. 【作業実施者】は作業者を記載している。
2. 【実施事項】は作業実施者に確認してもらう事項を記載している。
3. 【確認のポイント】は作業実施者が確認を行うためのポイントを記載している。
4. 【手段や手法】は作業実施者が確認するための具体的な手段や手法を記載している。
5. 【管理者提供の情報】はシステム管理者が作業実施者に対して提供すべき情報を記載している。

7

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

2.3.1 ステップ 1：I/O 比率の簡易確認
ユーザが実行しているジョブに対して I/O 比率を確認することにより I/O 効率改善の可能性の目安を簡単に判断するためのステップである。

【作業実施者】
ジョブを実行しているユーザを想定している。
【実施事項】
ユーザは CPU 時間と実行時間の割合である CPU 利用率を調査することにより I/O 比率を確認する。
ジョブの実行終了後に表示される時間については real(または elaps)、user、sys の 3 つに区分される。CPU
利用率は user を real で除算することにより算出される。CPU 利用率が低いプログラムは I/O 比率が高いと考えられる。各項目については、図 2.5 に示す。

図 2.5 実行時間の内訳
ユーザは実行時間に関する情報を採取する。設定については以下の通りである。
・ バッチ実行による運用が行われている場合にはシステム特有の実行時間を採取する方法が存在すると考えられるため、システム管理者に対してジョブごとの実行時間が収集されていることを問い合わせる。
・ インタラクティブ実行を主とした運用やバッチ実行による運用において実行時間を採取していない場合には pacct 情報の利用などを検討する。pacct 情報を採取する場合にはシステムに多少なりとも負荷を与えるため、適用に際しては十分に検討することを推奨する。なお、pacct を利用するためには、シス
テム管理者が計算サーバ上において psacct を起動させるとともに/var/account/pacct に対してユーザへの read 権を付与する必要がある。

【確認のポイント】
ユーザは実行時間において CPU 時間と I/O 時間の目安を確認する。
例として、インタラクティブ実行において time コマンドを利用した場合には“user÷real”によって算出される数値が目安値(各サイトの管理者が決定)以上あることを確認する。バッチ運用(ジョブ運用ソフトウェア)の場合にはuser時間はプロセス数(コア数)で積算されているため、”(user÷process数(コア数))÷実行時間(real)”の値が目安値以上であることを確認する。
もし、目安値以下の場合には、I/O 時間が想定以上に長いことが一因と考えられ、実行時間を短縮できる可能性があるため、2.3.2 ステップ 2 に進むことを推奨する。また、2.3.3 ステップ 3 に進み詳細に調査することも可能である。目安値については【管理者提供の情報】に示す。
【手段や手法】
確認の例として、(1)逐次ジョブ/インタラクティブ実行、(2)逐次ジョブ,並列ジョブ/インタラクティブ実行
および、(3)逐次ジョブ,並列ジョブ/バッチ実行の場合について示す。

(1)逐次ジョブ/インタラクティブ実行/L-FS,N-FS,P-FS
情報を採取するため time コマンドを利用する。time コマンドでは以下の情報を表示できる。
8

サイエンティフィック・システム研究会

real
user
sys

ファイルシステム利用技術 WG

成果報告書：ジョブの開始から終了までの時間(実行時間)：プログラム自体の処理時間(CPU 時間)：OS 処理時間

想定対象を表 2.2 に示す。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.2 想定対象
逐次ジョブ
インタラクティブ実行
L-FS,N-FS,P-FS

一例として、逐次ジョブをインタラクティブ実行し、その直後に情報を表示する場合を図 2.6 に示す。マーカーの箇所が計算に必要な値である。
実際の例を用いて“user÷real”の値を計算する。
user 0.76 秒 ÷ real 26:27.30 = 0.000478% /usr/bin/time -f " real %E \n user %U \n sys %S \n" ./IOR -w -r -b 1g -F -e -s 32 -i 2
省略
Max Write: 138.34 MiB/sec (145.06 MB/sec)
Max Read: 264.51 MiB/sec (277.36 MB/sec)
Run finished: Tue Jan 20 10:34:43 2015
real 26:27.30
user 0.76
sys 180.39

図 2.6 time コマンドにおける実行時間の内訳の表示方法(2)逐次ジョブ,並列ジョブ/インタラクティブ実行/L-FS,N-FS,P-FS
並列ジョブでは time コマンドを利用した情報の採取が困難なため、dump-acct コマンドを利用して情報を採取する。なお、本方法は逐次ジョブに対しても適用可能である。
また、計算サーバを跨ぐ並列ジョブの場合には全ての計算サーバにおいて dump-acct コマンドを利用して情報を採取する。
dump-acct コマンドは以下のフィールド情報が採取可能である。表示される数値は 10ms 単位であるため、秒に換算する場合には注意が必要である。また、各フィールドの意味は以下の通りである。
第一フィールド(1) ： プロセス名
第二フィールド(2) ： user 10ms 単位
第三フィールド(3) ： sys 10ms 単位
第四フィールド(4) ： real 10ms 単位
想定対象を表 2.3 に示す。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.3 想定対象
逐次ジョブ,並列ジョブ
インタラクティブ実行
L-FS,N-FS,P-FS

例として、並列ジョブをインタラクティブ実行し、情報を採取して表示する場合を図 2.7 に示す。マーカーの箇所が計算に必要な値である。
実際の例を用いて“user÷real”の値を計算する。
user 320ms ÷ real 1204940ms = 0.000265% /usr/sbin/dump-acct /var/account/pacct | /bin/grep IOR
IOR | 32.0|8448.0|120494.0| 2057| 2057|･･････省略 |Tue Jan 20 06:37:14 2015
(1)

(2)

(3)

(4)

9

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

図 2.7 dump-acct コマンドにおける実行時間の内訳の表示方法(3)逐次ジョブ,並列ジョブ/バッチ実行/N-FS,P-FS
バッチ実行ではシステム固有の採取方法により実行時間を採取できるため、ジョブ実行後に出力される情報(ジョブ統計情報と呼称)を利用する。本ケースではジョブスケジューラとしてジョブ運用ソフトウェアを利用しており、出力されるジョブ統計情報の中で必要な情報は以下の通りである。
JOB START DATE
：ジョブ実行開始時刻
この差が real に相当
JOB END DATE
：ジョブ実行終了時刻
JOB END DATE – JOB START DATE ：実行時間
USER CPU TIME
：プログラム自体の処理時間(CPU 時間)= user に相当
SYSTEM CPU TIME
：OS 処理時間= sys に相当
CPU NUM (USE)：アシスタントコア 2 個を含んだ使用 CPU 数(計算サーバ内)ジョブが使ったコア数は、表示される数より 2 を減算する
想定対象を表 2.4 に示す。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.4 想定対象
逐次ジョブ,並列ジョブ
バッチ実行
N-FS,P-FS

例として、I/O ジョブを実行した場合を図 2.8、CPU ジョブを実行した場合を図 2.9 に示す。
ジョブ統計情報の Node Information は 1 台の計算サーバにおける統計情報である。 1 台の計算サーバは 32
コアと 2 アシスタントコアで構成される。計算サーバ 2 台を跨ぎ 2 コアを利用して実行した。
実際の例を用いて“user÷real”の値を計算する。
(user 51023ms ÷ ( 3 コア -2 アシスタントコア )) ÷ (09:49:17 – 9:30:57) = 0.0442％ /bin/cat ./SS_IOR.i30005
Job Information
JOB IDJOB NAMEJOB TYPE: 30005: SS_IOR: BATCH省略JOB START DATEJOB END DATE

: 2015/01/21 09:30:57: 2015/01/21 09:49:17

省略---------------------------------------------------------------------Node Information
NODE ID: 0xFF10000B

省略
CPU NUM (ALLOC): 34
MAX MEMORY SIZE (USE): 66.3 MiB (69435392)
CPU NUM (USE):3USER CPU TIME (USE): 51023 ms
SYSTEM CPU TIME (USE): 805152 ms
CPU TIME (TOTAL): 856175 ms
DISK SIZE (USE):I/O SIZE: 549757.6 MB (549757573016)
FILE I/O SIZE
: 549757.1 MB (549757061905)
EXEC INST NUM:0
EXEC SIMD NUM:0------------------------------------------------------------------------

図 2.8 I/O ジョブとして IOR を用いて 2 並列で実行した例
CPU ジョブは 36 台の計算サーバを利用しており、1 台の計算サーバあたり 2 プロセスを割り当て全体として
72 並列で実行した。1 プロセスあたり 16 スレッドの処理を行っている。
実際の例を用いて“user÷real”の値を計算すると 0.9 より大きな値となる。
10

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書(user 29663089ms ÷ ( 34 コア -2 アシスタントコア )) ÷ (11:12:52 - 10:56:12) = 0.926％ /bin/cat ./SS_HPL.i30008
Job Information
JOB IDJOB NAMEJOB TYPE: 30008: SS_HPL: BATCH省略JOB START DATEJOB END DATE

: 2015/01/21 10:56:12: 2015/01/21 11:12:52

省略-----------------------------------------------------------------------Node Information
NODE ID: 0xFF040001

省略
CPU NUM (ALLOC)
MAX MEMORY SIZE (USE)CPU NUM (USE)USER CPU TIME (USE)SYSTEM CPU TIME (USE)CPU TIME (TOTAL): 34: 28138.7 MiB (29505519616): 34: 29663089 ms: 9838 ms: 29672927 ms

省略

図 2.9 CPU ジョブとして HPL を用いて 72 並列で実行した例【管理者提供の情報】
システム管理者は各サイトにおいて任意の目安値を決定する。
まず、目安値を決定する際の参考として I/O ジョブと CPU ジョブの両極端な事例を以下に示す。
・I/O ジョブの例
本書では I/O ジョブとして IOR HPC Benchmark(IOR と呼称)を利用した。
プログラムの入手先は、http://sourceforge.jp/projects/sfnet_ior-sio/releases/である。
・CPU ジョブの例
本書では CPU ジョブとして High-Performance Linpack Benchmark(HPL と呼称)を利用した。
プログラムの入手先は、http://www.netlib.org/benchmark/hpl/である。
上記の 2 つのジョブを実行して得られた情報より、【確認のポイント】の計算式から算出した目安値は以下の通りである。 例 1 はインタラクティブ実行であり、例 2 はバッチ実行の例である。
例 1-1．IOR をインタラクティブ実行(図 2.6 の値)
user 0.76 秒 ÷ real 26:27.30 = 0.000478
例 2-1. IOR をバッチ実行(図 2.8 の値)(user 51023ms ÷ ( 3 コア -2 アシスタントコア )) ÷ (09:49:17 – 09:30:57) = 0.0442
例 2-2. HPL をバッチ実行(図 2.9 の値)(user 29663089ms ÷ ( 34 コア -2 アシスタントコア )) ÷ (11:12:52 – 10:56:12) = 0.926
あるサイトでは、I/O ジョブは 0.1 より小さな値、CPU ジョブは 0.9 に近い値になることがわかっている。
次に、各サイトにおける目安値の作り方(例)は以下の通りである。
システムでジョブの実行時間を採取する設定を行った後、もしくは、すでに情報が採取されている場合は、一定期間（例えば 一年間など）の課金情報（ジョブ毎の実行時間や user 時間）を抽出して目安値を計算する。ジ
ョブ毎に計算した値に対して各サイトの特性に応じて統計処理、平均値、分布、などをもとに各サイトの運用ポ
リシーなどを勘案して目安値を決定する。

11

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

2.3.2 ステップ 2：想定 I/O 量,想定 I/O 性能,システム負荷の確認
ユーザが実行しているジョブに対してステップ 1 よりさらに詳しく I/O 効率改善の可能性を確認し、判断するためのステップである。本ステップでは大別して 3 つの観点(I/O 量の目安、I/O 性能の目安、ファイルシステム
負荷)を確認する。

2.3.2.1 想定 I/O 量の確認【作業実施者】
ジョブを実行しているユーザを想定している。
【実施事項】
ユーザはジョブの実行に先立ちジョブの想定 I/O 量を確認する。
ジョブを実行した後に表示されるI/O 量と想定I/O 量を比較することにより想定以上にread,write などが発生していないことを確認する。I/O の例を図 2.10 に示す。

図 2.10 ジョブ実行時の I/O 例【確認のポイント】
ユーザはアプリケーション(プログラム)の変更や入力データを変更した場合には、過去の実績と比較してほぼ想定に即した I/O 量であることを確認する。
一例として、ファイルサイズと同程度の I/O 量であることが挙げられる。もし、ファイルサイズの数倍の I/O
量がある場合には、重複した read, write の発生が一因と考えられ、I/O 効率改善の可能性がある。
なお、ジョブ実行において複数ファイルが read,write される場合は、I/O 量はそれぞれのファイルに対するI/O 量の合算値になる。
想定より多くの I/O 量がある場合には実行時間を短縮できる可能性があるため、2.3.3 ステップ 3 に進むことを推奨する。
想定したI/O量の場合においても、
ステップ1でI/O比率が目安値以上の場合には lseek,open, closeなどのメタデータ操作の回数が多い場合があるため、2.3.3 ステップ 3 に進み調査する。
また、I/O 量の確認においては、主に以下のような理由によりファイルシステムの構成や種類などによってファイルサイズと異なる数値になるため注意が必要である。
・ ファイルシステムのキャッシュにヒットした場合は I/O 量が少なく表示される。
・ ファイルのアクセス時に特定のシステムコ－ル（例. mmap）を利用すると I/O 量が少なく表示される。
・ ファイルシステムの機能により事前に先読みされる仕組みを有する場合にはI/O量が少なく表示される。

【手段や手法】
確認の例として、(1)逐次ジョブ/インタラクティブ実行、(2)逐次ジョブ,並列ジョブ/インタラクティブ実行
および、(3)逐次ジョブ,並列ジョブ/バッチ実行の場合について示す。

12

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書(1)逐次ジョブ/インタラクティブ実行/L-FS,N-FS,P-FS
情報を採取するため time コマンドを利用する。time コマンドではオプションを指定することにより以下の情報を表示できる。
real：ジョブの開始から終了までの時間(実行時間)
user：プログラム自体の処理時間(CPU 時間)
sys：OS 処理時間
io：総 I/O 量
想定対象を表 2.4 に示す。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.4 想定対象
逐次ジョブ
インタラクティブ実行
L-FS,N-FS,P-FS

IOR を利用してジョブの I/O を模擬した。IOR では 64GB の write を行った後に read を 64GB 行う。これを 2回繰り返す。想定 I/O 量は 256GB である。
例を図 2.11 に示す。ジョブ実行後にマーカーの箇所では約 256GB の I/O 量がある。
もし、想定より多い I/O 量が表示された場合には 2.3.3 ステップ 3 に進み調査する。
また、図 2.12 のように N-FS(NFS)ではキャッシュの効果により小さな値になることもある。 ただし、0kbと表示される場合にはさらに詳細な分析が必要（第 3 章参照）である。
local-single% /usr/bin/time -f "real %E \nuser %U \nsys %S \nio %Okb\n" ./IOR -w -r -b 1g -F -e -s 64 -i 2
省略
Max Write: 138.34 MiB/sec (145.06 MB/sec)
Max Read: 264.51 MiB/sec (277.36 MB/sec)
Run finished: Tue Jan 20 10:34:43 2015real 0:57.72
real 26:27.30
user 0.76
sys 180.39
io 278734376kb

図 2.11 L-FS(ext4)における逐次ジョブ実行時の I/O 量nfs-single%/usr/bin/time -f "real %E \nuser %U \nsys %S \nio %Okb\n" ./IOR -w -r -b 1g -F -e -s 64 -i 2
省略
Max Write: 110.31 MiB/sec (115.67 MB/sec)
Max Read: 111.45 MiB/sec (116.87 MB/sec)
Run finished: Tue Jan 20 06:57:18 2015
real 20:04.94
user 0.34
sys 88.94
io 134217744kb

図 2.12 N-FS(NFS)における逐次ジョブ実行時の I/O 量(2)逐次ジョブ,並列ジョブ/インタラクティブ実行/L-FS,N-FS,P-FS
並列ジョブでは time コマンドを利用した情報の採取が困難なため、/proc 配下の情報から I/O 量の情報を採取する。情報を採取する場合には事前にジョブが実行される一部の計算サーバにログインして/proc 配下の情報を表示させる。なお、本方法は逐次ジョブにおいても適用可能である。

13

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

想定対象を表 2.5 に示す。
ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.5 想定対象
逐次ジョブ,並列ジョブ
インタラクティブ実行
L-FS,N-FS,P-FS

IOR を利用してジョブの I/O を模擬した。IOR では 32GB の write を行った後に read を 32GB 行う。これを 2回繰り返す。計算サーバ 1 台に対して並列プロセス数は 2 を指定したため想定 I/O 量は 256GB である。
例を以下に示す。ジョブを実行する前に計算サーバにログインしてコマンドを実行(図 2.13)した後に並列ジョブを実行させる(図 2.14)。図 2.13 のマーカーの箇所の通り、rchar 約 42GB(キャッシュヒットは含まれていない)、 wchar 約 68GB の I/O 量がある。
もし、想定より多い I/O 量が表示された場合には 2.3.3 ステップ 3 に進み調査する。0kb と表示された場
合にはさらに詳細な分析が必要（第 3 章参照）である。
nfs-para% /usr/bin/watch –n1 '/bin/cat /proc/`/usr/bin/pgrep IOR`/io'
Every 1.0s: /bin/cat /proc/19083/io

Tue Jan 20 07:12:42 2015rchar: 221931
wchar: 31074297546
省略
Every 1.0s: /bin/cat /proc/19084/io

Tue Jan 20 07:31:35 2015rchar: 42289819898
wchar: 68719477852
省略

図 2.13 L-FS や N-FS における並列ジョブ実行時の I/O 量
fefs% mpiexec –n 2 -–hostfile ./hostfile ./IOR -w -r -b 1g -F -e -s 64 -i 2

図 2.14 P-FS における並列ジョブ実行の例
また、ファイルシステムが N-FS(NFS)の場合には 図 2.15 マーカーの箇所のコマンドを組み合わせることにより、情報を採取(MPI を用いた並列ジョブの場合にはマスタノードのみ集計)することができる。採取した情報において表示された数字(NFS: READ 2215621 WRITE 4196790)はブロック数であり、この値を NFS のマウ
ントオプションによって表示されるサイズ(rsize や wsize)と積算することにより概算の I/O を算出できる。なお、本例では NFS マウントが 1 つの環境である。
% /bin/cat ./IOR_TEST-Multi.sh
SRNIO=`/usr/sbin/nfsstat -3 -c -l | /bin/awk '/read:/{print $5}'`
SWNIO=`/usr/sbin/nfsstat -3 -c -l | /bin/awk '/write:/{print $5}'`
mpiexec –n 2 -–hostfile ./hostfile ./IOR -w -r -b 1g -F -e -s 64 -i 2
ERNIO=`/usr/sbin/nfsstat -3 -c -l | /bin/awk '/read:/{print $5}'`
EWNIO=`/usr/sbin/nfsstat -3 -c -l | /bin/awk '/write:/{print $5}'`
NREAD_BLK=`/usr/bin/expr $ERNIO - $SRNIO`NWRITE_BLK=`/usr/bin/expr $EWNIO - $SWNIO`
echo "NFS: READ $NREAD_BLKWRITE $NWRITE_BLK "% sh ./IOR-TEST-TSS-Multi.sh
NFS: READ 2215621

WRITE 4196790

図 2.15 NFS における I/O 量の表示の例
nfsstat コマンドによって表示されるサイズは図 2.16 マーカーの箇所の数字である。

14

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書% /usr/sbin/nfsstat -m/home from :/homefs
Flags: rw,relatime, vers=3, rsize=32768, wsize=32768, namlen=255, hard8, proto=tcp,･･････省略

図 2.16 NFS のマウントオプションによって表示される数字の例
P-FS（FEFS）では、IOR を利用してジョブの I/O を模擬した。IOR では 64GB の write を行った後に read を
64GB行う。
これを2回繰り返す。
計算サーバ1台に対して並列プロセス数は2を指定したため想定I/O量は512GBである。
ジョブを実行する前に1 つの計算サーバにログインしてコマンドを実行(図2.17)した後に並列ジョブを実行させる(図 2.15)。マーカーの箇所の通り 1 つのプロセスにて rchar 約 76GB、wchar 約 128GB の I/O 量がある。
もし、想定より多くの I/O 量が表示された場合には 2.3.3 ステップ 3 に進み調査する。0kb と表示された
場合にはさらに詳細な分析が必要（第 3 章参照）である。
fefs-para% /usr/bin/watch –n1 '/bin/cat /proc/`/usr/bin/pgrep IOR`/io'
省略
Every 1.0s: /bin/cat /proc/7067/io

Tue Jan 20 08:51:39 2015rchar: 221935
wchar: 20119037651
省略
Every 1.0s: /bin/cat /proc/7068/io

Tue Jan 20 09:11:00 2015rchar: 76062879998
wchar: 137438954596
省略

図 2.17 P-FS(FEFS)における I/O 量の表示の例
また、P-FS(FEFS)は図 2.18 のマーカーの箇所のコマンドを組み合わせることにより、情報の採取(MPI を用いた並列ジョブの場合にはマスタノードのみ集計)が可能である。
※ 図 2.18 の/*/は並列分散ファイルシステムのマウントが 1 つの場合に利用できる。
% /bin/cat ./IOR_TEST-Multi.sh:
SLIO=`/bin/cat /proc/fs/lustre/llite/*/stats | /bin/grep _bytes`
slread=`echo $SLIO | /bin/awk '/read_bytes/{print $7}'`
slwrite=`echo $SLIO | /bin/awk '/write_bytes/{print $7}'`
mpiexec –n 2 -–hostfile ./hostfile ./IOR -w -r -b 1g -F -e -s 64 -i 2
ELIO=`/bin/cat /proc/fs/lustre/llite/*/stats | /bin/grep _bytes`
elread=`echo $ELIO | /bin/awk '/read_bytes/{print $7}'`
elwrite=`echo $ELIO | /bin/awk '/write_bytes/{print $7}'`
READ_BYTE=`/usr/bin/expr $elread - $slread`
WRITE_BYTE=`/usr/bin/expr $elwrite - $slwrite`
echo "Lustre : READ $READ_BYTE
WRITE $WRITE_BYTE "% sh ./IOR-TEST-TSS-Multi.sh
Lustre : READ 274890493185

WRITE 274890493185

図 2.18 P-FS における I/O 量の表示の例
P-FS(FEFS)の/proc/fs/lustre/llite/*/stats において各フィールドの意味を以下に示す。
第一フィールド(1) ： 処理回数
第二フィールド(2) ： 最小 I/O 長
第三フィールド(3) ： 最大 I/O 長
第四フィールド(4) ： I/O 量(統計)15サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

例として、図 2.18 の実行結果を図 2.19 に示す。マーカーの箇所が計算に必要な値である。
% /bin/cat /proc/fs/lustre/llite/*/stats
省略
read_bytes

3488783 samples [bytes] 1(1)(2)
954772 samples [bytes] 0

write_bytes

33198293 1791105480465(3)(4)
2097152 251366446186

省略% sh ./IOR_TEST-Multi.sh省略% /bin/cat /proc/fs/lustre/llite/*/stats
省略
read_bytes
write_bytes

4537378 samples [bytes] 1
2003348 samples [bytes] 033198293 2065995976478
2097152 526244353130

図 2.19 P-FS(FEFS)における I/O 量の例(3)逐次ジョブ,並列ジョブ/バッチ実行/P-FS
バッチ実行ではシステム特有の情報を取得できるため、ジョブ実行後に出力されるジョブ統計情報より I/O
量の情報を採取できる。情報を採取する場合にはジョブ実行時に追加オプションを指定する。
想定対象を表 2.9 に示す。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.9 想定対象
逐次ジョブ,並列ジョブ
バッチ実行
N-FS,P-FS

IOR を利用してジョブの I/O を模擬した。IOR では 128GB の write を行った後に read を 128GB 行う。これを 2回繰り返す。計算サーバ 2 台に対して並列プロセス数は 2 を指定したため想定 I/O 量は 1TB である。
例を図 2.20 に示す。ジョブ実行後にマーカーの箇所の通り、約 1TB の I/O 量がある。また、Node Informationに表示される各計算サーバの情報では約 0.5TB の I/O 量があることがわかる。
もし、想定より多くの I/O 量が表示された場合には 2.3.3 ステップ 3 に進み調査する。 0kb と表示された場
合にはさらに詳細な分析が必要（第 3 章参照）である。
fefs-para％ /bin/cat ./SS_IOR.i30005
Job Information
JOB ID: 30005
JOB NAME: SS_IORJOB TYPE: BATCH
省略
FILE I/O SIZE

: 1099513.1 MB (1099513035484)

省略Node Information
NODE ID: 0xFF10000B

省略
FILE I/O SIZE

: 549757.1 MB (549757061905)-----------------------------------------------------------------------Node Information
NODE ID: 0xFF11000B

省略
FILE I/O SIZE

: 549756.0 MB (549755973579)

図 2.20 ジョブ運用ソフトウェアにおける I/O 量の表示の例

16

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書【管理者提供の情報】
システム管理者はファイルシステムの構成情報や設定パラメタの意味や意図を提供することが望ましい。
一例として、ファイルシステムのマウント情報をユーザが参照しやすい場所(/etc/motd など)に記載するなどが挙げられる。

2.3.2.2 想定 I/O 性能の確認【作業実施者】
ジョブを実行しているユーザを想定している。
【実施事項】
ユーザはジョブを実行するにあたり想定 I/O 性能を確認する。
ジョブを実行した場合には I/O 性能を確認することによりファイルシステムとジョブの I/O 特性が合致していることを確認する。
※ライフサイエンス分野や検索を主とするジョブでは小I/OアクセスやDBへの頻繁なアクセスが想定されており、I/O 性能が I/O 特性チューニングの参考情報とならないことも多いため、該当するジョブについては 2.3.3
ステップ 3 に進むことを推奨する。
【確認のポイント】
ユーザはアプリケーション(プログラム)の実行時にジョブの I/O 性能とシステムの典型的な I/O 性能値に乖離が少ないことを確認する。システムの典型的な I/O 性能値の例は【管理者提供の情報】に示す。
乖離が大きい場合には I/O 効率改善の可能性がある。ただし、ジョブが I/O している時間が短い場合は検知が難しいため、より詳細な I/O 時間を調査するには 2.3.3 ステップ 3 に進むことを推奨する。
【手段や手法】
確認の例として、(1)逐次ジョブ,並列ジョブ/インタラクティブ実行、(2)逐次ジョブ,並列ジョブ/バッチ実行の場合について示す。

(1)逐次ジョブ,並列ジョブ/インタラクティブ実行/L-FS,N-FS,P-FS
ジョブが実行されている間、システムの典型的な I/O 性能値との乖離を確認するため、iotop コマンドを利用して情報を採取する。情報の採取ではジョブ実行直後にアクセスが発生する場合があるため、ジョブが実行される計算サーバにおいて事前に iotop コマンドを実行することを推奨する。
また、逐次ジョブ/インタラクティブ実行/L-FS は情報を採取できるツールが豊富なため、性能情報の採取方法は参考情報とする。なお、逐次ジョブ/インタラクティブ実行/N-FS,P-FS については適用が可能である。

想定環境を表 2.7 に示す。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.7 想定対象
逐次ジョブ,並列ジョブ
インタラクティブ実行
L-FS,N-FS,P-FS

IOR を利用してジョブの I/O を模擬した。write した後に read され、その一連のアクセスを 2 回繰り返す。
このプロセスが 2 並列で実行される。
例を以下に示す。
ジョブを実行する前に計算サーバにログインしてiotop コマンドを実行(図2.21)した後にジョブを実行させ

17

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書た時の例である(図 2.22)。
マーカーの箇所の通り、1 つ目のプロセスの write では約 75MB/s、2 つ目のプロセスの write では約 82MB/sの性能を確認できる。同様に 1 つ目のプロセスの read では約 86MB/s、2 つ目のプロセスの read では約 72MB/sの性能を確認できる。
もし、この性能が 10kb/s や検知できない場合には 2.3.3 ステップ 3 に進み調査する。 0kb と表示された
場合にはさらに詳細な分析が必要（第 3 章参照）である。
local-para% /usr/bin/iotop -d 30
Total DISK READ: 812.68 B/s | Total DISK WRITE: 155.81 M/s
TID PRIO USERDISK READ DISK WRITE SWAPIN
IO>

COMMAND省略
TID PRIO USER
1730 be/4 root
23245 be/4 abebe
23246 be/4 abebe

DISK READ DISK WRITE
812.68 B/s 73.81 K/s
0.00 B/s 75.11 M/s
0.00 B/s 82.33 M/s

SWAPINIO>
COMMAND
0.00 % 94.23 % [flush-8:0]
0.00 % 94.15 % ./IOR~TEST/test
0.00 % 93.55 % ./IOR~TEST/test

省略
Total DISK READ: 159.06 M/s | Total DISK WRITE: 3.18 K/s
TID PRIO USERDISK READ DISK WRITE SWAPIN
IO>
COMMAND
23246 be/4 abebe
86.76 M/s
0.00 B/s 0.00 % 99.73 % ./IOR -w~TEST/test
23245 be/4 abebe
72.29 M/s
0.00 B/s 0.00 % 97.59 % ./IOR -w~TEST/test
省略
Total DISK READ: 0.00 B/s | Total DISK WRITE: 158.91 M/s
TID PRIO USERDISK READ DISK WRITE SWAPIN
IO>
COMMAND
23245 be/4 abebe
0.00 B/s 88.15 M/s 0.00 % 94.18 % ./IOR -w~TEST/test
23246 be/4 abebe
0.00 B/s 70.79 M/s 0.00 % 94.17 % ./IOR -w~TEST/test
省略
Total DISK READ: 135.87 M/s | Total DISK WRITE: 16.67 K/s
TID PRIO USERDISK READ DISK WRITE SWAPIN
IO>
COMMAND
23245 be/4 abebe
67.14 M/s
0.00 B/s 0.00 % 99.99 % ./IOR -w~TEST/test
23246 be/4 abebe
68.73 M/s
0.00 B/s 0.00 % 94.07 % ./IOR -w~TEST/test

図 2.21 L-FS における I/O 性能の表示の例
local-para% mpiexec –n 2 -–hostfile ./hostfile ./IOR -w -r -b 1g -F -e -s 64 -i 2

図 2.22 L-FS における並列ジョブ実行の例
N-FS(NFS)の例を以下に示す。
ジョブを実行する前に計算サーバにログインしてiotop コマンドを実行(図2.23)した後にジョブを実行させた時の例である(図 2.24)。
マーカーの箇所の通り、
1 つ目のプロセスの write では約 189MB/s、
2 つ目のプロセスの write では約 205MB/sの性能を確認できる。同様に 1 つ目のプロセスの read では約 54MB/s、2 つ目のプロセスの read では約 47MB/sの性能を確認できる。
もし、この性能が 10kb/s や検知できない場合は 2.3.3 ステップ 3 に進み調査する。また、read に対して
write の性能が高い場合には NFS の sync オプションにより、L-FS の write 完了を待ち合わせることなく I/Oの完了通知がされているために高い性能が表示されている場合がある。
同様に write に対し read 性能が高い場
合には NFS のキャッシュヒットによる性能値が表示されている場合がある。ただし、0kb と表示された場合にはさらに詳細な分析が必要（第 3 章参照）である。

18

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

nfs-para% /usr/bin/iotop -d 30
Total DISK READ: 0.00 B/s | Total DISK WRITE: 4.66 K/s
TID PRIO USERDISK READ DISK WRITE SWAPIN
IO>

成果報告書

COMMAND省略
TID PRIO USER
19083 be/4 abebe
19084 be/4 abebe

DISK READ DISK WRITE SWAPIN
IO>
COMMAND
0.00 B/s 189.26 M/s 0.00 % 85.50 % ./IOR -w~TEST/test
0.00 B/s 205.29 M/s 0.00 % 84.67 % ./IOR -w~TEST/test

省略
Total DISK READ: 11.84 K/s | Total DISK WRITE: 6.65 K/s
TID PRIO USERDISK READ DISK WRITE SWAPIN
IO>
COMMAND
19084 be/4 abebe
54.04 M/s
0.00 B/s 0.00 % 96.27 % ./IOR -w~TEST/test
19083 be/4 abebe
47.93 M/s
0.00 B/s 0.00 % 89.42 % ./IOR -w~TEST/test
省略

図 2.23 NFS(N-FS)における I/O 性能の表示の例
nfs% mpiexec –n 2 -–hostfile ./hostfile ./IOR -w -r -b 1g -F -e -s 32 -i 2

図 2.24 NFS(N-FS)における並列ジョブ実行の例
P-FS(FEFS)の例を以下に示す。
ジョブを実行する前に計算サーバにログインしてiotop コマンドを実行(図2.25)した後にジョブを実行させた時の例である(図 2.26)。
マーカーの箇所の通り、
1 つ目のプロセスの write では約 122MB/s、
2 つ目のプロセスの write では約 120MB/sの性能を確認できる。
read は FEFS の先読み機能が有効であるため、
iotop コマンドでは表示されない。
ただし、
write において 0kb と表示される場合にはさらに詳細な分析が必要（第 3 章参照）である。
fefs-para% /usr/bin/iotop -d 30
Total DISK READ: 0.00 B/s | Total DISK WRITE: 7.17 K/s
TID PRIO USERDISK READ DISK WRITE SWAPIN
IO>

COMMAND省略
TID PRIO USER
636 be/3 root
7067 be/4 abebe
7068 be/4 abebe

DISK READ
0.00 B/s
0.00 B/s
0.00 B/s

DISK WRITE
407.82 B/s
122.27 M/s
120.57 M/s

SWAPINIO>
COMMAND
0.00 % 0.31 % [jbd2/sda3-8]
0.00 % 0.00 % ./IOR -w~RGE_TEST
0.00 % 0.00 % ./IOR -w~RGE_TEST

省略
Total DISK READ: 0.00 B/s | Total DISK WRITE: 1631.40 B/s
TID PRIO USERDISK READ DISK WRITE SWAPIN
IO>
COMMAND
7067 be/4 abebe
0.00 B/s
0.00 B/s 0.00 % 19.49 % ./IOR -w~RGE_TEST
7068 be/4 abebe
0.00 B/s
0.00 B/s 0.00 % 1.94 % ./IOR -w~RGE_TEST省略※DISK READ は表示されない

図 2.25 P-FS(FEFS)における I/O 性能の表示の例
fefs% mpiexec –n 2 -–hostfile ./hostfile ./IOR -w -r -b 1g -F -e -s 32 -i 2

図 2.26 P-FS（FEFS）における並列ジョブ実行の例(2)逐次ジョブ,並列ジョブ/バッチ実行/P-FS
バッチ実行ではジョブ実行中の I/O 性能の情報採取が困難である。情報を採取するためには、個別に情報を収集する必要があり、この集計を自動的に行う仕組みの jobstats を検討中である。

19

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

想定対象を表 2.14 に示す。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.14 想定対象
逐次ジョブ,並列ジョブ
バッチ実行
P-FS

【管理者提供の情報】
システム管理者はSS研 大規模ストレージWGの成果である健康診断ツールなどを活用して比較元のデータを作成する。その結果からシステムの典型的な I/O 性能値を公開(例えば各サイトのシングルストリーム性能、短 I/O
長の I/O 性能、複数プロセスにおける I/O 性能の総和など)することが望ましい。

2.3.2.3 システム負荷の確認【作業実施者】
ジョブを実行しているユーザを想定している。
【実施事項】
ユーザはジョブが実行された時刻のファイルシステムの負荷状況を確認する。ジョブ実行中はファイルアクセ
スの集中、 ファイルシステムの縮退などの理由によって、ファイルシステムが高負荷となり I/O 性能が十分に出ない状態ではなかったことを確認する。ファイルシステム負荷が低い場合は write が高速に行え、ファイルシス
テム負荷が高い場合は write の性能が発揮できない状況の例を図 2.27 に示す。

図 2.27 出力時にファイルシステムの能力が十分に発揮できない状態の例【確認のポイント】
ユーザはジョブが実行された時刻にファイルシステムが高負荷状況でないこと、ファイルシステムやデータ転送経路が縮退していないことを確認する。
ファイルシステムが高負荷な場合には I/O 時間が長くなることが想定され、その影響により実行時間も長時間化した可能性がある。この場合にはジョブの再実行により I/O 時間が改善される可能性がある。
【手段や手法】
確認の例として、(1)逐次ジョブ,並列ジョブ/インタラクティブ実行、(2)逐次ジョブ,並列ジョブ/バッチ実行の場合について示す。
一例として、ジョブが実行した時刻をもとに、各サイトの運用において提供されているシステム監視ツールからの情報によりシステムに異常があることを確認する。
20

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書(1)逐次ジョブ,並列ジョブ/インタラクティブ実行/L-FS,N-FS,P-FS
情報を採取するため date コマンドを利用してジョブの実行時刻を表示する。なお、本方法は逐次ジョブについても適用可能である。

想定対象を表 2.15 に示す。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.15 想定対象
逐次ジョブ,並列ジョブ
インタラクティブ実行
L-FS,N-FS,P-FS

例として、並列ジョブ実行直後に情報を表示する場合を図 2.28 に示す。マーカーの箇所が時刻である。
nfs% /bin/date; mpiexec –n 2 -–hostfile ./hostfile ./IOR -w -r -b 1g -F -e -s 32 -i 2 ; /bin/date2015 年 1 月 20 日 火曜日 06:37:13 JST
省略
Max Write: 110.31 MiB/sec (115.67 MB/sec)
Max Read: 111.45 MiB/sec (116.87 MB/sec)
省略
2015 年 1 月 20 日 火曜日 06:57:18 JST

図 2.28 date コマンドを利用した時刻表示の例
また、ls コマンドを用いることにより、出力ファイルのタイムスタンプからジョブが実行され時刻を推測できる。
例として、ジョブ実行直後に情報を表示する場合を図 2.29 に示す。マーカーの箇所が時刻である。
nfs% ./IOR -w -r -b 1g -F -e -s 32 -i 2 –k -E
省略
Max Write: 110.31 MiB/sec (115.67 MB/sec)
Max Read: 111.45 MiB/sec (116.87 MB/sec)
省略
nfs% ls –l testFile-rw-rw-r-- 1 abebe abebe 34359738368 1 月 20 06:37:15 2015 testFile

図 2.29 タイムスタンプを利用した時刻表示の例(2)逐次ジョブ,並列ジョブ/バッチ実行/N-FS,P-FS
バッチ実行ではシステム特有の情報を取得できるため、ジョブ実行後に出力されるジョブ統計情報から時刻情報を表示させる。統計情報の採取はジョブ実行時に追加オプションを指定する。出力されフィールドの意味を以下に示す。
JOB START DATE
：ジョブ実行開始時刻
JOB END DATE
：ジョブ実行終了時刻

21

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

想定対象を表 2.16 に示す。

ジョブの種類
実行方法の種類
ファイルシステムの種類

表 2.16 想定対象
逐次ジョブ,並列ジョブ
インタラクティブ実行
L-FS,N-FS,P-FS

例を図 2.30 に示す。マーカーの箇所が時刻の情報である。
％ /bin/cat ./SS_IOR.i30005
Job Information
JOB ID: 30005
JOB NAME: SS_IOR省略JOB START DATEJOB END DATE

: 2015/01/21 09:30:57: 2015/01/21 09:49:17

省略

図 2.30 ジョブ運用ソフトウェアを利用した時刻表示の例【管理者提供の情報】
システム管理者はシステム監視ツール(Ganglia[3]や縮退時に出力されるログの監視など)により、ファイルシス
テムの負荷状況や状態をユーザに公開する。(Web ベースによってファイルシステムの負荷状況を表示するなど)
また、ファイルシステムが高負荷な状態の場合にはユーザにアラームで通知するなどについて検討する。(例えば、片系に縮退しているなど)

2.3.3 ステップ 3：システムコール分析
ユーザが実行しているジョブに対してシステムコールごとの分析を行うステップである。

【作業実施者】
ジョブを実行しているユーザとシステム管理者の共同作業を想定している。
【実施事項】
ユーザは該当するジョブのシステムコールごとの時間を分析するコマンドを追加してジョブを実行する。ジョブの実行後に 3 章に記載されているツールを活用することによりジョブの処理時間(real)におけるシステムコールの分布やシステムコールの発生タイミングを確認する。
【手段や手法】
本 WG における成果のひとつであるシステムコール分析ツール（IO-Dock と呼称）を活用する。IO-Dock の詳細については 3 章を参照されたい。
【確認のポイント】
ユーザやシステム管理者は、IO-Dock を活用して I/O に関するシステムコールを分析する。また、ジョブを実行している時刻にファイルシステムが高負荷な状態ではないことを確認する。IO-Dock の結果からジョブの実行
時間と I/O 時間の割合を算出した後に I/O 時間の割合が低いことを確認する。
I/O時間の割合が高い場合はIO-Dockの結果を可視化し、システムコール（read,write,unlink,lseek,open,closeなど）の発生のタイミングを確認する。確認した結果から想定していたアプリケーション（プログラム）の挙動と合致していない場合や I/O 効率改善の見込みのある場合には、プログラムを改良するなどについて検討する。
プログラム改良の実績と効果の例については 4 章を参照されたい。
[3]

Ganglia

http://sourceforge.jp/projects/sfnet_ganglia/
22サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書【管理者提供の情報】
システム管理者は IO-Dock による分析方法と効果（実績など）をサイトに公開や管理することを検討する。

2.3.4 ステップ 4：システム管理者による詳細分析
システム管理者がシステムに対してどのような調査や分析が必要であるかを検討するためのステップである。

【作業実施者】
システム管理者や調達責任者を想定している。
【実施事項】
システム管理者（調達責任者）は運用しているシステムにおいてファイルシステムが高負荷に推移した原因や、ジョブの実行時間の特異点を調査する。
【手段や手法】
システムの各コンポーネントから出力されるログ情報を収集して調査に活用する。
例として、ファイルサーバの縮退メッセージ、 ネットワークの縮退メッセージ、ls コマンドのレスポンス、など、通常運用の状態との差異を手がかりにシステムの高負荷の原因と経過を調査する。なお、ファイルシステ
ムに対する負荷を調査する場合にはメタサーバへのアクセス情報の記録と管理も必要となる。
注意）メタデータに関して対象は Lustre(FEFS)のみ

2.4 将来的に採取したい項目について
本 WG では I/O 効率の改善の方法とあわせてファイルシステム利用技術の更なる改善や発展に向け、将来的に必要と考えられる項目について議論を行った。以下に具体的な項目をまとめる。

(1) I/O の測定技術
・ ユーザが情報を採取する方法では正確な性能情報を表示できない。これはファイルシステムのキャッシュや先読み機能によるものである。P-FS(FEFS)では read 性能値はユーザやシステム管理者のコマンド操作によって情報採取できないことが判明しており、今後、本性能情報を採取する仕組みが必要である。
・ ファイルシステムの性能や運用状況を監視するための機能や仕組みが求められている。一例として評価用のプログラムを作成し、定期的に実行してファイルシステムの変化(システムコール応答時間)を検知して監視することもひとつの解になりうると考える。
・ 今回の WG におけるプログラム分析において、read,write,open,close などのシンプルなシステムコールのほかに mmap もプログラミングにおいて利用されていることが判明した。調査において mmap の I/O 情報を採取できないために十分な分析ができなかったこと、および、今後も mmap がプログラミングで利用される傾向が続くと考えられるため、mmap の I/O 情報が表示できる機能が必要である。
・ システムにおいて特異点が発生することが危惧されている。本 WG の議論では特定ユーザのジョブが実行されるとシステムが不安定な状態になる事例が報告された。その中で原因特定にいたるまでに時間を要したことを考えてジョブの実行状態だけでなく、サーバ、ネットワーク、ストレージなどのそれぞれの情報を関連付けてジョブからディスクまでの状態を総合的に監視できるツールが必要となる。

(2) I/O 部分のチューニング支援・ バッチ実行においてチューニング支援のための情報が不足している。そのため、I/O 情報を自動に集計する
仕組みのjobstatsなどを活用する。
jobstatsはジョブ運用ソフトウェアと連携してジョブを特定するため、ジョブごとの I/O 性能の情報を採取できる。この検討中の機能によりジョブごとの I/O 統計情報（jobstatsなど）によって性能を確認する。さらに、時系列に詳細に知る仕組みを fefsvr として検討しており、この
ジョブ I/O 情報の可視化ツール（fefsvr）を活用することによって I/O 特性を確認する。
※対象は FEFS を想定(3 章参照)されたい。
23

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

・ CPU や演算手法に関するチューニングガイドは存在するが、I/O に関するガイドはあまり提供されていない。
そのため、プログラムのデバッグにおいて、計算ループ内に write を記載したままシミュレーションを行う
場合や、過去から実績のあるプログラミングでは I/O 回数が増える傾向がある、といった事例を収集し、事例集としてまとめることが必要である。さらに、「ソースコードと IO-Dock の分析情報の対応表示」や「システムコールにおいて mmap の I/O 情報の表示」もあわせて必要になる。
また、本 WG の活動の成果報告書は中上級者向けとなっているため、I/O に関するガイド、特に｢初心者向けの I/O 事例集｣を提供することはユーザのモチベーションをあげる方法として有効であると考える。

(3) 並列 I/O の普及とファイルシステムを含む情報採取
・ ユーザが情報を採取する場合には並列ジョブに対する情報採取が難しいことが判明した。今回は目安としての情報採取であるが、今後は並列 I/O などのより高度な I/O 手法がユーザに浸透すると考えるため、並列 I/Oに関する情報採取の仕組みが必要となる。
・ ファイルシステムにはキャッシュの概念があり、アクセス時間の揺らぎはキャッシュヒットの有無と考える傾向があるが、明確な原因の特定までいたらない場合があった。このため、原因特定の分析を行うためのク
ライアントとファイサーバ側の OS の統計情報を収集して簡単に照合できる仕組みが必要である。
・ ファイルシステムが高負荷となる原因について様々な観点から特定するための情報として、ファイルシステ
ムが高負荷時のジョブ一覧、システムのハードウェアの状態一覧（DISK のリビルド状態、経路の縮退状態、
通信エラー数、など）、ファイルシステムの状態一覧(メタサーバ状態、ディスク多重アクセス状態、高 load
値サーバ、など)、各ハードウェアの最大性能値一覧(サーバ、ネットワーク、ストレージ、ストリーム性能、
ランダム性能など)、などの情報を採取する仕組みや、これらの情報とファイルシステムの挙動との関連性を分析する仕組みが必要である。

24

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

3 分析ツール
本章では本 WG で作成、及び検討した分析ツールについて報告する。

3.1 背景現状、システムでアプリケーションの実行時間が長いという問い合わせがあった場合、OS やファイルシステムの統計情報を参照し、システムに対する負荷を調査することで、そのアプリケーションがシステムのリソースを効率よく最大限に利用できているか、あるいは他の要因（システム故障、高負荷のアプリケーションとの並列実行など）で遅くなっているか切り分けることができる[4]。
ただし、同一アプリケーションを異なるシステムで動作させ処理時間が大きく異なるような場合、統計情報だ
けではその原因の調査は困難である。特にファイルシステムはそのシステム構成や動作仕様でアプリケーション
からの I/O 処理時間が大きく変わるため、アプリケーションの実行時間が大きく変わる一因となっている。異なるシステム間での処理時間の差異の調査は、ユーザがプロファイラを使用しアプリケーションの動作を解析することで原因箇所を切り分けることが可能であるが、プロファイラを使いこなしてアプリケーションをチューニン
グするユーザはごく一部に限られると推測される。

図 3.1 4 階層モデル
システムやアプリケーションの動作を確認するには図 3.1 に示すように 4 階層それぞれで得られる下記の情報を総合的に確認する必要がある。
ハードウェア：独自インタフェース
装置自体で採取できる統計情報（コントローラの処理量/処理回数等）
OS：標準コマンドsysstat（sar，iostat，mpstat）を使用した OS レベルでの統計情報
ファイルシステム：独自インタフェース
各ファイルシステム独自の統計情報表示機能を使用したレベルの統計情報
JOB：独自ツール
ジョブ管理ソフトの出力する統計情報やプロファイラでの解析情報

ユーザは主に JOB レベルの情報を解析するしかなく、ファイルシステムといったシステムの共有部分が原因で
アプリケーションの動作が遅くなっていた場合は、従来はシステム管理者に問い合わせるしかなかった。また、システム管理者は特定のアプリケーションがシステムの共有資源を独占して使ってしまうことでシステム全体の性能影響が出た場合に、原因となったアプリケーションの特定や問題個所を指摘することが困難であった。

[4]

資料 2「モニタリング技術紹介」を参照
25

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

3.2 目的本 WG では、ユーザがシステムの共有部分であるファイルシステムに対するアプリケーションの I/O 処理内容を把握して、ファイルシステムを効率良く使用できているかどうかを確認できるツールを検討した。本ツールを利用することによる期待効果は以下の 3 点である。
●I/O 量の把握
ユーザが自分のアプリケーションから発行される I/O 量を認識することで意図通りに I/O ができているのか確認する。
●実行時間の短縮
アプリケーションの I/O パターンを確認してそれぞれのファイルシステムが得意な I/O パターンに改善することで実行時間を短縮する。
●システム負荷の軽減
ユーザが意図しない動作で無駄に I/O を出してファイルシステムのリソースを使っている場合、原因箇所を特定し修正することでファイルシステム負荷を軽減する。
また、システム管理者が各アプリケーションの発行する I/O 量を把握するために今度どのような仕組みが必要になるかを検討した。

3.3 ユーザレベルでの分析ツールの作成
アプリケーションが発行する I/O 処理内容を利用者が把握するために作成したツールについて紹介する。

3.3.1 システムコール分析ツール「IO-Dock」の紹介[5]アプリケーションから発行されるシステムコール（Unix 系）を記録し解析することで、アプリケーションの動作特性を分析することができる。本 WG では記録されたシステムコールの内、ファイルシステムに関連があるものに着目し、処理回数、実行時間や I/O 量などの集計を行うツール「IO-Dock（アイオードック）」を作成した。
集計する項目は以下の通りとした。
●処理回数
システムコール毎に実行回数とエラーになった回数を集計する。システムコールが意図せずに発行回数が多い場合やエラーになっていた場合にはアプリケーション側の動作やシステム設定を確認する必要がある。
●処理時間
システムコール毎のトータル処理時間、1 回毎の処理時間の最大値、最小値、平均値を集計する。システ
ムコールのトータル処理時間が多い場合はアプリケーションの改善を検討し、処理時間にばらつきがある
場合はシステム側に異常がなかったかを問い合わせる必要がある。
●I/O 量アプリケーションからの総 read/write 量やファイル毎の総 read/write 量を集計する。意図しない特定のファイルへの集中的なアクセス等を検出可能である。
●I/O サイズ
アプリケーションからの read や write の I/O サイズをファイル毎に集計する。
ファイルシステム毎に得意な I/O サイズがあるため、その特性に合わせてアプリケーションを修正することで I/O 性能の改善が期待できる。
●ファイルオフセット
ファイル毎にファイルオフセットの時間的な推移を表示する。意図せず同じオフセットにデータを上書きしているような無駄なアクセスを行っているケースを検出可能である。アプリケーションを修正すること
で性能の改善が期待できる。
これらを用いて、アプリケーションを修正することで実行時間を短縮できる。
[5]

システムコール分析ツール「IO-Dock」は SS 研 Web サイトからダウンロード可能。
http://www.ssken.gr.jp/MAINSITE/download/wg_report/fs/index.html
26

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書【動作概要】
本ツールは strace（Linux）または truss（Solaris）により採取した、アプリケーションのシステムコールのトレースログを入力とする。
本ツールで解析可能な形式でログファイルを採取するため、以下のオプションを指定してコマンドを実行する。
●strace（Linux 用）# strace –fttT –o <ログファイル> <実行コマンド>●truss（Solaris 用）# truss –aefldE –vall –rall –wall –o <ログファイル> <実行コマンド>
実際の入力データの例を図 3.2、図 3.3 で示す。太枠で囲ったところがアプリケーションの発行したシステム
コールで、本ツールはファイル I/O に関係するものに絞って処理を行う。

図 3.2 strace の入力ファイル例

図 3.3 truss の入力ファイル例27

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書【分析フロー】
分析の流れは以下の通りである。なお実行例ではベンチマークソフトウェアの IOzone の strace 出力結果を基に実施した（IO-Dock の詳細な仕様は付録の資料 2 を参照）。
①

システムコール毎に集計する。
まずは、I/O 処理全体を把握するためシステムコール毎に集計を行い、実行回数、エラー回数、総処理時間を確認する。例えば、実行回数が多いもの、エラーの多いもの、処理時間が長いものに着目し次のステップに進む。IO-Dock の実行例を図 3.4 に示す。

図 3.4 IO-Dock 実行例（system コール毎の集計）②

着目したシステムコールの発行対象のファイル毎に集計する。
着目したシステムコールの発行対象のファイル毎に集計を行い、実行回数、エラー回数、処理時間を確認する。特定のファイルに対して特定のシステムコールの実行回数が多い、もしくは実行時間が長い場合、そのファイルへの I/O アクセスパターンの処理を見直すことを検討する。またエラーが多発している場合はシス
テム資源を無駄に使用している可能性があるため、可能な限りエラーを減らすようにアプリケーションを修正するのが望ましい。図 3.5 の IO-Dock の実行例では write システムコールを対象ファイル毎に集計して表示している。

図 3.5 IO-Dock 実行例（write システムコールの内訳）
また、read や write の量や処理時間が多い場合は次のステップに進む。次の③では図 3.5 の対象ファイルから処理時間の多かった/work3/tmp/workfile に着目して分析する。

28

サイエンティフィック・システム研究会

成果報告書

ヒストグラムやアクセスパターンを確認する。
着目した read や write 対象のファイルに対し、I/O 長毎のヒストグラムの分析や、経過時間毎のファイルポ
インタの offset を確認することで、ファイルシステムの苦手な I/O 長でシステムコールを発行していない
か、もしくは同じ offset に対して無駄な I/O を発行していないか等を確認する。まず、IO-Dock を実行して対象ファイル（/work3/tmp/workfile）への IO 長のヒストグラムデータ出力し（図 3.6）、データを Excel
で加工すると図 3.7 のようなヒストグラムが得られる。

図 3.6 IO-Dock の実行例（ヒストグラムデータの出力例：一部）

IO長③

ファイルシステム利用技術 WG

1B
～4 B
～16 B
～64 B
～256 B～1 KiB～4 KiB～16 KiB～64 KiB～256 KiB～1 MiB～4 MiB～16 MiB

write

1

100

10000

1000000

図 3.7 IO-Dock の実行例（write の IO 長ヒストグラム）

29サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

また、同様に IO-Dock を実行して、対象ファイルへの write システムコールの実行時間と offset の変化を経
過時間の推移と共に表示したものを図 3.8、図 3.9 に示す。

図 3.8 IO-Dock 実行例（write システムコール実行時間の推移）

図 3.9 IO-Dock 実行例（write offset の推移）

30

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

3.4 システム管理者レベルでの分析ツールの検討
IO-Dockはユーザが自分のアプリケーションのI/O処理内容を確認したい場合に使われることを想定している。
システム管理者の立場で見ると、アプリケーション毎の I/O 発行量を把握し、システムのリソースをどれだけ使用しているのかを把握しておきたい。このようなニーズに対して今後必要になってくる分析ツールを検討した。

3.4.1 I/O Accounting 情報の利用
Linux kernel の機能で、プロセス毎に read/write の実行バイト数や実行回数を表示可能である（図 3.10）。集
計可能な情報は表 3-1 の通りである。

図 3.10 I/O Accounting 機能のイメージ

rchar，wchar
syscr，syscw
read_bytes
write_bytes
cancelled_write_bytes

表 3.1 I/O accounting 機能
read，write システムコールの実行 byte 数
read，write システムコールの実行回数
ブロックデバイスからページキャッシュにロードされた byte
数ページキャッシュ上で dirty フラグが立った byte 数デバイスに書き込まれる前に cancel された byte 数

I/O Accouting 機能を利用してジョブ単位に I/O を可視化する場合は、以下のような機能の作り込みが必要である。動作イメージを図 3.11 と①～③で示す。
① クライアント内でジョブとそのプロセスの括り付けを行う。
② 定期的に I/O Accounting の情報を読み出して記録する。
③ ジョブが実行された全クライアントから②の情報を収集して外部ノードで集計する。

31

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

図 3.11 I/O Accounting 機能の統計情報集計（検討中）
I/O Accounting 機能を利用した場合、クライアント毎に統計情報が記録されるため、クライアント台数が大きくなるにつれて外部ノードでの集計に時間がかかるようになる。また daemon に①のプロセスとジョブの括り付ける機能が必要なためジョブスケジューラとの連携が必要になり実装コストが高い。また、I/O Accounting 機能自体にはファイルのメタ系（open/close/stat 等）の処理回数が含まれないため，ファイルシステムのメタデータ
処理ネックになっているかどうかは分析できない。

3.4.2 ジョブ統計情報の利用(fefsvr)
Lustreで実装された機能でクライアントから送信されるリクエストにkey情報を埋め込み、サーバ側でそのkey
情報を元に集計するものである（key 情報にできるのは process 名_PID や特定の環境変数）。サーバ側の/proc 経
由で統計情報（read/write 回数/量、メタ操作回数）をデバイス（ディスクのボリューム）単位に参照可能である。図 3.12 に動作イメージと図 3.13 に表示例を示す。ファイルシステムで実装された機能であるため、I/O
accounting 機能では集計されなかったメタ系の処理回数も集計できるようになっており、ファイルシステムの負荷状況がより詳細にわかるようになっている。

図 3.12 ジョブ統計情報の動作イメージ32

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

図 3.13 ジョブ統計情報
このジョブ統計情報を全サーバから回収して集計すると図 3.12 の様にジョブ単位で I/O 量がわかり、ユーザが自分のアプリケーションが発行するI/O量がどのぐらいなのか判断することができる。
富士通のFEFSではfefstop
コマンドで実現している。

図 3.14 fefstop コマンドの実行例
fefstop は実行中ジョブについて一定時間だけの I/O 量を集計するが、ジョブ実行中の I/O 量の時間的な推移を把握して、I/O 量の多いジョブの特定や、一時的なシステム性能劣化の影響を受けてジョブの実行時間が長くなったことを切り分けるために、常にジョブ毎の I/O を記録しておきたいというニーズもある。このため、このジョブ統計情報を定期的に読み出して集計/記録することで、ジョブからファイルシステムに対して発行されたリクエストを時系列に整理して表示できる機能を検討した。
（fefsvr（仮称）、未提供機能）この機能はサーバ内にジョブ統計情報を定期的に読み出して記録する daemon を常駐させ、daemon が記録したデータを外部ノードに転送し集計することでジョブの経過時間の遷移と I/O 量を可視化するものである。図 3.15に動作イメージ、図 3.16 にジョブ単位時集計した read/write 量の経過時間の推移のイメージを示す。これによりシステム管理者はジョブ毎の I/O 特性を把握でき、ファイルシステムのリソースを使いすぎているジョブの特定や、同一ジョブのデータを比較することでシステム異常が発生したかどうかを知ることが可能になる。

33

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

図 3.15 fefsvr の動作イメージ（検討中）

図 3.16 fefsvr の出力イメージ（検討中）

3.5 まとめ
ファイルシステムに対するアプリケーションの I/O 状況を可視化できるツールの作成や将来検討を行った。
IO-Dock はシステムコール単位やファイル単位で細かく挙動を追跡し、システムの設定やアプリケーションの意図していない動作（I/O ライブラリを使用した場合も含む）で遅くなっている原因を特定できるため、アプリ
ケーションの I/O 処理時間を短縮できる。その一方で、strace や truss を使用してログファイルを採取する必要があるため、採取対象のアプリケーションの実行時間が極端に長くなり日常的に使用することは難しい。また、
ソースコード上の具体的な修正箇所/修正方法を提示できないため、分析データからアプリケーションに反映するためにはシステムに精通している必要がある。IO-Dock 自体はまだ発展途上のツールであるが、本 WG において各会員のシステムで動作するアプリケーションに適用することで問題を検出し、改善することができた（詳細は 4章で報告する）。IO-Dock は I/O ライブラリの発行するシステムコールまで可視化でき、ユーザがまったく意図していないところで性能が遅くなっていることがわかるため、今回の IO-Dock を使った活動での気づきは大変役にに立った。
システム管理者でジョブ毎の I/O 量を把握するために I/O Accounting 機能と Lustre のジョブ統計情報機能を利用した分析ツールを検討した。I/O Accounting 機能を使った場合、ファイルシステムに縛られず汎用的に使うことができるが、取得できる情報が限られており I/O 量を十分に把握できない。ジョブ統計情報機能を利用した
fefsvr（仮称）は特定のファイルシステム上での動作に限られるが、ファイルシステムの統計情報を利用できる
ためより細かな I/O 負荷状況を把握できる。システム管理者は集計された情報を参照し、I/O 量の多いジョブの特定やシステム異常による実行遅延の検出が可能となる。また、ユーザはアプリケーションからの I/O を可視化することで I/O チューニングへのきっかけになる。

34

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4 分析ツールによる解析事例
4.1 宇宙航空研究開発機構
4.1.1 概要
4.1.1.1 システム概要
JSS(JAXA Supercomputer System)は，総演算ピーク性能約 141TFLOPS の計算エンジン部，合計 11PB の容量を持つストレージ部と，統合スパコン環境を提供する分散環境統合部からなる(図 4.1.1)．計算エンジン部には、様々な計算需要に対応するために 4 つのサブシステム、M システム(Main システム)、P システム(Project システム)、
A システム(Application システム)、V システム(Vector システム)を用意している。ストレージ部は，実効容量
1PB，総実効転送性能 25GB/s の RAID5 装置と，総容量 10PB，LTO4 ドライブ 40 台，LTO3 ドライブ 8 台の LTO ライ
ブラリ装置を SAM-QFS で階層管理している。図 4.1.2 に，ストレージ部の構成概要を示す．また，JSS の主要計
算エンジンである M システムをクライアントとした場合のファイルシステム構成を図 4.1.3 に示す．JSS の計算
エンジン部は調布事業所に設置されているが、これを角田、相模原、筑波の各事業所からもシームレスに利用するために、分散環境統合部は、ログインノード機能を提供する L システム(Local システム)と、遠隔共有ファイル機能を提供する J-SPACE(JSS’s Storage Platform for Archiving, Computing, and Exploring)を、これら 3事業所に配置している。
ストレージ部は，ネットワークファイルシステム，ローカルファイルシステムと階層ストレージ管理，OS のデバイスドライバ，ストレージエリアネットワーク，ストレージデバイスから構成される．ネットワークファイル
システムは富士通社製の SRFS: Shared Rapid File System を用いており，ネットワークへのインターフェースとして DDR InfiniBand と Ethernet を持つ．DDR InfiniBand インターフェースにより M システムと A システムを，
EthernetインターフェースによりLシステムを収容できる．
ローカルファイルシステムはORACLE社製のQFS:Quick
File System を用いており，大規模シーケンシャルアクセス時に高い性能が出るように設計・構築してある．ローカルファイルシステムからストレージデバイスまでは冗長構成をとっており，各部分の一部に故障が発生しても，迂回経路やバックアップ機能を用いてユーザへのファイルシステムサービスを継続できるようになっている．
ストレージ部では，数千並列という高並列度演算においても，総実効転送性能 25GB/s を確保しつつ，ファイルシステムが自動的に排他制御を厳密に実施するシステムを構築することにより，ユーザのプログラム開発の時間を確保するよう努めた．また，物理的なストレージ媒体のエラー等によるデータ消失に備えるため，合計 11PBの容量を持つストレージ装置では，ディスク装置は RAID5 構成をとり，テープ装置へのアーカイブ時には同時に
2 つのテープ媒体に書き込みを行っている．

M-System

A-System

DDR InfiniBand

L-System

CPUs

Ethernet

Inter-/Intra- Connect Network
Network File System

SRFS/SRFS on Ether
SAM-QFS SAM-QFS SAM-QFS
Solaris10
Solaris10
Solaris10

図 4.1.1 JSS の全体構成

FC-SAN
SwitchFC-SAN
Switch

RAID
×90

LTO
×48

Local File System
Hierarchical Storage Management
OS
Storage Area Network

Storage Devices

図 4.1.2 ストレージ部の構成概要

35

サイエンティフィック・システム研究会

クライアント←IB ×3,008
IB:2GB/s
FC:0.4GB/s

DDR IB switch←IB ×54

108GB/s←3 servers

File server

ﾌｧｲﾙｻｰﾊﾞ

File Cache
36GB/sＳＡＮ(0.4GB/s)×180←FC ×(20+4)

FC ×90→FC switch(8+1.6)GB/s

成果報告書【ファイルシステム構成】

Compute node
←12,032cores / 3,008nodes
Computenode
ComputeFilenode
node
Cache
ComputeComputenode

2GB/s per node
(Total:6,016GB/s)
ｲﾝﾀｰｺﾈｸﾄ

ファイルシステム利用技術 WG

項目

3008
Open Solaris
4
32GB
2GB

・ファイルサーバ／クライアント間総バンド幅

108GB/s・ファイルサーバ数(メタデータサーバとデータ処理サーバ)
・ファイルサーバOS・ファイルサーバ一台当たりのコア数
・ファイルサーバ一台当たりのメモリ量

3
Solaris 10
128
1TB サーバキャッシュ 640GB・ファイルサーバ／ストレージ間総バンド幅36GB/s・ファイルシステム当たりのストレージ台数
・ストレージ処理能力(一台当たりのバンド幅)

90台
Read:400MB/s
Write:200MB/s

FC switch(FC×1)×180→←FC ×40

数値・クライアント数
・クライアントOS・クライアント一台当たりのコア数
・クライアント一台当たりのメモリ量
・クライアント一台当たりのインタコネクトバンド幅【運用方法】←FC ×4
項目

ストレージ
デバイス

RAID5
RAID5
RAID5

LTO4
LTO4

・ファイルシステムのブロック長
・quota有無
・データ暗号化有無
・ACL有無Metadata
RAID1

内容

1MB
あり
なし
あり

図 4.1.3 ファイルシステム構成

4.1.1.2 システム健康診断結果概要
図 4.1.3 のファイルシステムの特性を、SS 研大規模ストレージ WG 作成のファイルシステム健康診断ツールで測定した。このツールは、大規模ストレージの計測に適したファイルシステム性能測定の共通的なツールが存在しないため、複数のファイルシステム間での性能測定結果の比較が難しい現状に鑑み、測定ツール・測定項目をモデル化し、そのツールを使った測定結果を元に、大規模ストレージシステムの特性を簡易に診断する方法を提案するもので、大規模データ転送、データ量一定転送、メタデータアクセスという 3 つの性能を測定するツールである。詳細は、サイエンティフィック・システム研究会発行の「大規模ストレージ WG 成果報告書～大規模スト
レージの課題と今後の対応」をご覧いただきたい。
図 4.1.4～4.1.6 に「大規模ストレージ WG 成果報告書～大規模ストレージの課題と今後の対応」にある測定結果を引用する。図中に赤字吹き出しで測定結果の特徴を追記してある。なお、図 4.1.3 のファイルシステムは、
大 I/O 長、多数プロセス時に性能が発揮できるよう設計・構築を行ったものである。
図 4.1.4 は、大規模データ転送性能の測定結果を示すが、I/O 長 100MB 以上、プロセス数 50 以上で 1GB/s 以上の性能が出ており、設計に沿った性能が実現していることが確認できる。
図 4.1.5 は、データ量一定転送性能の測定結果を示すが、大データ量(1GB)、小データ量(100MB)ともに、I/O長による大きな性能変化は見られないことがわかる。また、プロセス数 50 以上であっても、1 ファイルが 1MB 以
下となる場合、性能が悪いことがわかる。
図 4.1.6 は、メタデータアクセス性能の測定結果を示すが、各メタデータ操作で操作数絶対値には差があるものの、ほとんどのものが 100 プロセスで性能が頭打ちになっていることがわかる。また、ディレクトリの statに関しては、50 プロセス以上で性能劣化が測定された。
以上をまとめると、大ファイル・大 I/O 長・多数プロセスでの性能を重視したシステムとして設計し、その通りの性能が出ている。また、ディレクトリの stat を行う場合は同時実行が 50 プロセス未満となるように配慮するということが、使用上の注意点として挙げられる。
この基礎データを踏まえ、次節以下のシステムコール分析を行った。

36

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

図 4.1.4 大規模データ転送

図 4.1.5 データ量一定転送

図 4.1.6 メタデータアクセス

37

成果報告書

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.1.2 システムコール分析結果
4.1.2.1 実行環境
図 4.1.3 の JAXA スーパーコンピュータシステム JSS 上で実行した。クライアントである Compute node から、
RAID5 ストレージデバイスへの I/O を分析している。

4.1.2.2 実行プログラム概要
2 つのプログラム(流体系プログラム、データ処理系プログラム)の I/O 特性の分析を行った。
(1)流体系プログラム
高並列の MPI による流体系のプログラムである。各ノードは殆ど同じ動作をする。MPI 並列度が大きいため全てのノードを対象にすると膨大なログを分析することになるため、4 つのノードを選んで分析を行った。
(2)データ処理系プログラム
MPI 並列化されていない、かなり昔から利用されているデータ処理系のプログラムである。約 100 ノードを同時に使用しプログラムを同時実行しているが、各ノードのプログラムは全く同じであるため、特定のノードでの実行結果を対象にログ分析した。

4.1.2.3 分析結果
(1)流体系プログラム
図4.1.7にシステムコールの回数の集計結果を示す。
赤地で示したメタデータアクセス系のシステムコール「open」、「stat」、「statvfs」の処理時間が、I/O 系のシステムコール「read」や「write」と比べて同等または 2 倍程度かかっていることがわかる。また、赤枠で囲んだ「write」性能がどのノードでも 22GB/s を超えていることがわ
かるが、図 4.1.3 に示した通り 1 ノード当たりのハードウェア I/O 速度は DDR InfiniBand の 2GB/s が上限である
ため、この測定値は Write キャッシュの性能を測定していると推測される。
続いて図 4.1.8 に、システムコール関数別の実行回数上位 5 つのファイルとその回数を集計した結果を示す。
実行回数の欄を見ると、「read」以外のシステムコールは同じファイルを 511～1022 回、open/close/stat してい
ることがわかる。冗長なファイル操作をしている疑いがあるが、現状のツールではソースコードのどこに対応しているのかまでは追跡することができない。
syscall
open
close
unlinkfstat
stat
statvfs
readwrite

実⾏回数 error回数 処理時間 k回/秒
2,057
1
57 ms
36.3
2,056
0
0 ms
2
0
1 ms
1.7
2,051
0
3 ms 820.4
3,077
0
6 ms 496.3
1,538
0
64 ms
24.0
5
0
5 ms
1.0
1,535
0
52 ms
29.5

IO量

15 MB
1271 MB

平均IO⻑

syscall
open
close
unlinkfstat
stat
statvfs
read
write

IO速度

3.0 MB
3.0 GB/s
0.8 MB 24.4 GB/s

ノード 1 の結果
syscall
open
close
unlinkfstat
stat
statvfs
readwrite

実⾏回数 error回数 処理時間 k回/秒
1,033
1
54 ms
19.3
1,032
0
0 ms
1
0
1 ms
0.8
1,028
0
2 ms 604.7
1,029
0
49 ms
21.2
514
0
40 ms
12.9
5
0
5 ms
1.0
511
0
54 ms
9.4

IO量

14 MB
1228 MB

実⾏回数 error回数 処理時間 k回/秒
1,034
2
52 ms
19.8
1,032
0
0 ms
1
0
1 ms
1.3
1,028
0
3 ms 380.7
1,029
0
5 ms 228.7
514
0
7 ms
74.5
5
0
5 ms
1.0
511
0
53 ms
9.7

IO量

15 MB
1271 MB

平均IO⻑

IO速度

3.0 MB
2.9 GB/s
2.5 MB 24.0 GB/s

ノード 2 の結果
平均IO⻑

syscall
open
close
unlinkfstat
stat
statvfs
read
write

IO速度

2.9 MB
3.0 GB/s
2.4 MB 22.6 GB/s

ノード 3 の結果

実⾏回数 error回数 処理時間 k回/秒
1034
2
52 ms
19.8
1,032
0
0 ms
1
0
0 ms
1,028
0
2 ms 685.3
1,029
0
25 ms
41.7
514
0
16 ms
31.7
5
0
5 ms
1.0
511
0
54 ms
9.4

IO量

15 MB
1253 MB

ノード 4 の結果

図 4.1.7 システムコール回数(流体系プログラム)

38

平均IO⻑

IO速度

2.9 MB
3.1 GB/s
2.5 MB 23.1 GB/sサイエンティフィック・システム研究会

ファイルシステム利用技術 WG

open (Top5)
ファイル

実⾏回数
1,022
511
511
1
1
2,057

成功
1,022
511
511
1
1
2,056

失敗
0
0
0
0
0
1

時間
k回/秒
51.8 ms
20
2.9 ms176
1.4 ms365
0.0 ms0.0 ms56.6 ms
36

実⾏回数
RESULT/shock5_jet1-3-reordered_0001.rslt
2,555
adc_body_jet1-3.txt
2,044
adc_stbl_jet1-3.txt
2,044
hist_cdclcm_jet1-3_1-1000000.txt
4
hist_resi_jet1-3_1-1000000.txt
4
合計
6,666

成功
2,555
2,044
2,044
4
4
6,666

失敗
0
0
0
0
0
0

時間
k回/秒
7.7 ms332
61.0 ms
34
1.4 ms 1,460
0.2 ms20
2.0 ms2
72.7 ms
92

実⾏回数
1,022
511
511
1
1
2,051

成功
1,022
511
511
1
1
2,051

失敗
0
0
0
0
0
0

時間
k回/秒
1.9 ms538
0.5 ms 1,022
0.1 ms 5,110
0.0 ms0.0 ms
2.5 ms
820

実⾏回数
511
511
511
1
1
1,538

成功
511
511
511
1
1
1,538

失敗
0
0
0
0
0
0

時間
k回/秒
1.1 ms465
59.8 ms
9
1.1 ms465
0.0 ms0.0 ms64.0 ms
24

RESULT/shock5_jet1-3-reordered_0001.rslt

adc_body_jet1-3.txt
adc_stbl_jet1-3.txt/etc/opt/FSUNf90cp/jwe_prof/tmp/FJSVpnple/j1751171/GMP_1815555.1773

合計

成果報告書

read
ファイル

実⾏回数

成功

失敗

1
1
1
1
1
5

1
1
1
1
1
5

0
0
0
0
0
0

実⾏回数
511
adc_stbl_jet1-3.txt
511
adc_body_jet1-3.txt
511
hist_cdclcm_jet1-3_1-1000000.txt
1
hist_resi_jet1-3_1-1000000.txt
1
合計
1,535

成功
511
511
511
1
1
1,535

失敗
0
0
0
0
0
0

GEOM/shock5-reordered_0001.geom

GEOM/shock5-reordered_0001.indx

PARAMDAT/usr/share/lib/zoneinfo/Japan/etc/opt/FSUNf90cp/jwe_prof
合計

時間

IO量

2.5 ms 14.8 MB
0.1 ms 141 KB
2.4 ms
3.2 KB
0.0 ms125 B
0.0 ms12 B
5.0 ms 14.9 MB

k回/秒
0
10
0

平均IO⻑

3.2 MB
125 KB
12.0 KB

IO速度
5.9 GB/s
1.4 GB/s
1.3 MB/swrite

stat (Top5)
ファイル

ファイル

RESULT/shock5_jet1-3-reordered_0001.rslt

時間
51.5 ms
0.1 ms
0.4 ms
0.1 ms0.0 ms52.1 ms

IO量

k回/秒
10
1.3 GB
1.1 MB 5,110
1.1 MB 1,278
32 KB
12 KB
1.3 GB

平均IO⻑
IO速度
2.5 MB 24.6 GB/s
2.1 KB 10.7 GB/s
2.1 KB
2.7 GB/s
32 KB
12 KB

fstat (Top5)
ファイル
RESULT/shock5_jet1-3-reordered_0001.rslt

adc_body_jet1-3.txt
adc_stbl_jet1-3.txt/etc/opt/FSUNf90cp/jwe_prof/tmp/FJSVpnple/j1751171/GMP_1815555.1773.1

合計
statvfs (Top5)
ファイル
RESULT/shock5_jet1-3-reordered_0001.rslt

adc_body_jet1-3.txt
adc_stbl_jet1-3.txt
GEOM/shock5-reordered_0001.geom

GEOM/shock5-reordered_0001.indx

合計

図 4.1.8 システムコール別実行回数上位 5 位のファイル名(2)データ処理系プログラム
図4.1.9 にシステムコールの回数、
図4.1.10 にread/write システムコールの実行回数を集計した結果を示す。
また、図 4.1.11 に read/write 量と時間の時系列変化のグラフを示す。図 4.1.9 に赤地で示した通り、「lseek」
システムコールが 30,202 回実行されているのに対し、「read」システムコール、「write」システムコールは、それより少ない24,704+1,005回実行されており、不必要なlseekが行われている可能性があることがわかる。
また、
図 4.1.10 を見ると、read は 4 つのファイルに集中していること、write に比べて read が極端に多いことがわかる。図 4.1.11 からは、write はジョブの開始時と終了時のみに実行されるのに対し、read はジョブ実行中に継続して実行されていることがわかる。
syscall
open
openatclose
unlinkfstat
fstat64
stat
stat64lstat
lstat64
lseek
read
write

実⾏回数 error回数 処理時間 k回/秒
4,167
5
65 ms
64
165
16
2 ms
72
6,030
0
80 ms
75
3
0
0 ms
7,804
35
0 ms 78,040
432
0
0 ms
1,153
858
1 ms
887
10
0
1 ms
20
3
0
0 ms
6
0
0 ms
30
30,20200 ms
24,7040
9.7 sec
2.5
1,005
0
0.9 sec
1.2

IO量

平均IO⻑

IO速度

14 GB
404 MB584 KB402 KB

1.5 GB/s
474 MB/s

図 4.1.9 システムコール回数(データ処理系プログラム)

39

サイエンティフィック・システム研究会

ファイル名
file1
file2
file3
file4
file5
/tmp/file6
file7/tmp/file8/tmp/file9
file10
file11

ファイルシステム利用技術 WG

回数 合計時間[sec] 総IO量[MB] 平均IO量[KiB]
6,616
4.4694
6,935
1,024
6,534
2.1041
3,115
466
3,059
1.3713
1,946
621
1,687
1.2035
1,665
964
147
0.1076
151
1,006
134
0.0992
140
1,019
133
0.1231137
1,006
59
0.042662
1,018
58
0.0421
60
1,012
1,224
0.00674737
1,224
0.0068
47
37

成果報告書

ファイル名
file4
/tmp/file2
file1/tmp/file3/tmp/file4
file5
file6

回数
71
67
70
59
58
218
211

read

合計時間
総IO量[MB] 平均IO量[KiB]
0.128874
1,014
0.157970
1,019
0.146767931
0.135562
1,018
0.1272
60
1,012
0.088
39
177
0.0691
33
152

write
図 4.1.10 read/write システムコール実行回数(a)write 量(b)write 時間(c)read 量(d)read 時間
図 4.1.11 read/write の時系列変化
40

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.1.3 考察
(1)流体系プログラム
上記分析結果より、1 ノード当たり 1 ファイルに 1GB 以上の書き込みを行い、メタデータアクセスも多い write
主体のアプリケーションである。詳細に述べると以下のようになる。
・1 ファイルにメタデータアクセス系処理を行いながら固定 I/O 長(2.4MB)で 511 回書き込みを行う。
・1 ファイル当たり 4,600 回(write1 回当たり 9 回)のメタデータアクセス系の処理を実行している。
・I/O 自体は非常に安定している。特に write は write キャッシュに収まるもので、非常に高速な実行結果となっている。
(2)データ処理系プログラム
上記分析結果をまとめると、次のようになる。
・プログラム全体で見ると、write 量は少なく、read が主体の動作をしている。
・read 時に lseek し、オフセットを変えつつもファイルの同じ領域を重複して読み込んでいる。その結果、ファイルサイズが 70MB 程度であるにも関わらず、GB 規模の read が行われることになっている。

4.1.4 まとめファイルシステム健康診断で測定したところシステムは設計通りの性能・特性を示しており、流体系プログラ
ムは、この性能・特性に合った安定した I/O をしていることが確認できた。また、write キャッシュが有効に働くパターンで write システムコールが発行されていることも観測された。よって、全体としては適切な I/O となっておりチューニングの余地はあまりないことがわかった。但し、メタデータアクセス系の処理が多いため、そのソースコードでの実行位置を知ることにより、この処理の最適化が可能である可能性があるが、現状の分析ツール IO-Dock ではソースコードとログの突合ができないため、別の手段で実行位置を特定する必要があり、ツール改善点のひとつと考えている。
データ処理系プログラムについては、前述の通り、プログラム全体で見ると、write 量は少なく、read が主体の動作をしており、read 時に lseek し、オフセットを変えつつもファイルの同じ領域を重複して読み込んでいる
結果、ファイルサイズが 70MB 程度であるにも関わらず、14GB の read を行っている。この動作は、このプログラ
ムが作成された当時、メインメモリ量が少ない計算機環境であったため、処理データが必要になる度に、ファイ
ルの中にある当該データを read により取り出すというコーディングが現在まで残っているものと考えられる。
現在の計算機のメインメモリはファイルをメモリ上に読み込んでしまうだけの容量を十分備えているため、(1)ファイル全体をメモリ空間に読み込み、メモリ空間上で処理データを重複読み込みする動作に変更する、(2)read+lseek
を mmap を使ったポインタ操作+memcpy に変更する、等の高速化の対策が考えられる。今後改善対策を適用していく予定である。

41

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.2 京都大学人文科学研究所附属東アジア人文情報学研究センター
4.2.1 概要
4.2.1.1 システム概要
京都大学人文科学研究所附属東アジア人文情報学研究センターでは、全国漢籍データベース[6]や拓本文字デー
タベース[7]などの巨大データベースを運用しており、そのアクセス数は、年間 1000 万トランザクションを超えている。WWW のインターフェース部分は Intel/Linux で分散運用しているが、バックエンドのデータベースそのものは SPARC/Solaris(現在は、SPARC M10 + ETERNUS 2000)で運用している。以下のシステムコール分析を行った
時点での OS は SPARC/Solaris 10、ZFS のバージョンは v4 である。
本センターのデータベースにおいては、WWW からのアクセス(データベースクエリ)に関しては、複数のキャッシング手法を組み合わせることによって、そこそこの性能を引きだせている。しかし、問題はデータベースの更新、特に全国漢籍データベースの更新に、かなりの時間を要することだった。

4.2.2 システムコール分析結果
4.2.2.1 実行環境
本センターの全国漢籍データベースは、全国 72 機関が所有する漢籍(中国の古典文献)の目録データベースであり、約 90 万レコードから成っている。各レコードは、それぞれ別々の XML ファイルで構成されており、データベース更新時に単一の XML ファイルに組み上げた上で、OpenText7 のインデックスファイルを作成する。更新の頻度は、多い時では週 5 回、少ない時でも週 2 回程度はあり、その都度、夜中に更新をおこなっている。
この更新プログラムが、本センターでは問題となっていた。更新に関係するレコード数にもよるのだが、運悪
く 90 万レコード全てを更新せざるを得ない場合は、朝までに更新が終わらない(実時間で 8 時間以上かかってしまう)時があるのだ。WWW からのデータベースクエリを切らずに更新をおこなうため、更新のための CPU リソースを制限せざるを得ない、という事情もあるのだが、CPU を多めに割り当てても更新が遅い場合もあって、原因がわからず難渋していた。

4.2.2.2 実行プログラム概要
全国漢籍データベースの更新プログラムは、
Makefile から呼び出される /bin/sh スクリプトおよび OpenText7の dbbuild70 から成る。更新プログラムは、各レコードを単一の XML ファイルにまとめ上げた上で、dbbuild70
により、OpenText7 のインデックスファイルを作成する。更新プログラムのログの採取には、Solaris の truss
コマンドを用いた。
truss -aefldE -vall -rall -wall -o <ログファイル> <実行コマンド>

4.2.2.3 分析結果 (2013 年 7 月 4 日)
truss ログの取得をおこなうと、データベース更新にさらに多くの実時間を要する。感覚的に 4 倍程度の時間がかかるため、更新量が小さい時を狙ってログを取得し、その中で、2013 年 7 月 4 日のデータベース更新ログを分析した。約 32 万レコードの更新で、取得に 4 時間 20 分を要し、2 億ラインにも渡る巨大なログを分析した結果は、ファイルの open が 127 万回、close が 159 万回あり、これが実行速度のボトルネックとなっているのではないか、という結論だった(表 4.2.1 および 4.2.2)。特に、libc_psr.so.1 と libc.so.1 を、それぞれ 32 万回ず
つ open しており、さらには /var/ld/ld.config の open が 32 万回ほど ENOENT エラーが発生していた(表 4.2.3)。
これらは、いずれも無駄なシステムコールであるように思えた。

[6]
[7]

全国漢籍データベース
拓本文字データベース

http://kanji.zinbun.kyoto-u.ac.jp/kanseki
http://coe21.zinbun.kyoto-u.ac.jp/djvuchar42サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

表 4.2.1 2013 年 7 月 4 日 IO-Dock 分析結果(メタ I/O 系システムコール)
システムコール
実行回数 error 回数
処理時間
I/O 量

メタデータ

ファイル I/O

open(open64)
close
unlinkmkdir
rmdir
fstat64
lstat64
stat(stat64)
read
write

1,273,463
1,590,634
22
1
1
636,990
1,138,103
1,592,675
12,047,329
1,283,041

318,2882
4
0
0
0
7
637,377
038,27332.1 sec
33.1 msec
854 msec
0.10 msec
0.10 msec
25.1 msec
18.6 sec
5.54 sec
110.4 sec
58.6 sec

2.7GB
1.7GB

表 4.2.2 2013 年 7 月 4 日 IO-Dock 分析結果(ファイル I/O)

システムコール

read(TOP5)

write(TOP5+α)

ファイル

実行回数

処理時間

データ量

I/O 速度kanseki.cat

550,72939.1 sec

1.35 GB34.5 MB/s

tagint.XX

46,13212.9 sec

377.9 MB29.2 MB/skanseki.ip

45,69911.3 sec

374.3 MB33.1 MB/skanseki.i1

6

4.9 sec

187.1 MB38.1 MB/skanseki.t1
kanseki.cat
tmpalldat
tagint.XX
kanseki.idx
kanseki.t1
kanseki.i1
kanseki.ip

1
104
19
23,066
22,84922,84922,849182,792

4.8 sec
24.0 sec
0.0 sec
4.4 sec
4.0 sec
3.9 sec
3.6 sec
0.5 sec

187.1 MB451.1 MB
48 KB
188.9 MB187.1 MB187.1 MB187.1 MB187.1 MB38.9 MB/s
18.8 MB/s
6.8 MB/s
42.9 MB/s
46.7 MB/s
47.9 MB/s
51.9 MB/s
374.2 MB/s

表 4.2.3 2013 年 7 月 4 日 IO-Dock 分析結果(ファイル open 成功・失敗)
ファイル
ファイル数
open 成功
open 失敗/platform/FJSV,GPUZC-M/lib/libc_psr.so.1/lib/libc.so.1
その他共有ライブラリ/var/ld/ld.config
data/FA*/tagged*/*.dat
その他

1
1
8
1
318,169123

43

318,275
318,272182
0318,025432

000318,272016

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.2.2.4 再分析結果 (2014 年 4 月 15 日)
データベース更新用のプログラムをレビューしてみたところ、libc_psr.so.1 や libc.so.1 あるいは
/var/ld/ld.config を open するシステムコールは、/bin/sh スクリプトのうち、以下に示す while ループに集中していることが疑われた。
while read F
do echo '<OTDoc><OTFile>'"$F"'</OTFile>'
cat "$F"
echo '</OTDoc>'done
この while ループには、標準入力から更新すべき XML ファイルの一覧表が流し込まれ、標準出力からは、まとめあげた単一の XML が流れ出る。
2013 年 7 月 4 日のデータベース更新は、
約 32 万レコードに渡っており、
この while
ループ中の cat コマンドが 32 万回程度、実行される。そこで、この while ループを、nawk を用いて、以下のよ
うに書き換えてみた。
nawk '{
f=$0;
printf("<OTDoc><OTFile>%s</OTFile>\n",f);while((getline u<f)>0)
printf("%s\n",u);close(f);printf("</OTDoc>\n");}'このように書き換えてみたところ、更新プログラム全体の体感速度は 3 倍ほど速くなった。そこで、truss ログを取得し、
更新量の近い(約 20 万レコード)2014 年 4 月 15 日のデータベース更新ログを、
IO-Dock で分析した。
そうしたところ、open も close も約 20 万回にまで減少し、特に libc_psr.so.1 と libc.so.1 および/var/ld/ld.config へのアクセス数も 300 回程度に激減した(表 4.2.4～4.2.6)。ログの取得も 52 分で終了した。
これだけの書き換えで、実速度として 3 倍以上の高速化が確認できたことになる。

表 4.2.4 2014 年 4 月 15 日 IO-Dock 分析結果(メタ I/O 系システムコール)
システムコール
実行回数
error 回数
処理時間
I/O 量

メタデータ

open(open64)

200,348259

3.7 sec-

close

200,9842

6.8 msec-

unlink17

4

720 msec

-

mkdir

1

0

0.2 msec

-

rmdir

1

0

0.0 msec-

fstat64

398,7270

2.6 msec-

lstat64

872,5355

22.7 sec

-

2,851

1,589

85.5 msec-

stat(stat64)
ファイル I/O

read

1,065,063

079.7 sec

2.7GB

write

2,968,714

39,21951.6 sec

1.7GB

44

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

表 4.2.5 2014 年 4 月 15 日 IO-Dock 分析結果(ファイル I/O)
システムコール
ファイル
実行回数
処理時間
データ量

read
(TOP5)

write(TOP5+α)

I/O 速度kanseki.cat

566,58836.1 sec

1.39 GB

38.4 MB/s

tagint.XX

47,23612.3 sec

386.9 MB31.2 MB/skanseki.ip

47,06910.7 sec

385.5 MB35.7 MB/skanseki.i1

6

5.1 sec

192.7 MB37.3 MB/skanseki.t1

1

4.4 sec

192.7 MB43.2 MB/skanseki.cat

105

21.6 sec

462.4 MB21.4 MB/s

tmpalldat

2,629,037

13.5 sec

224.8 MB16.5 MB/s

tagint.XX

23,6184.5 sec

193.4 MB42.3 MB/skanseki.idx

23,5344.5 sec

192.7 MB42.5 MB/skanseki.t1

23,5344.0 sec

192.7 MB47.8 MB/skanseki.i1

23,534

3.9 sec

192.7 MB49.1 MB/skanseki.ip

188,267

0.6 sec

192.7 MB296.5 MB/s

表 4.2.6 2014 年 4 月 15 日 IO-Dock 分析結果(ファイル open 成功・失敗)
ファイル
ファイル数
open 成功
open 失敗/platform/FJSV,GPUZC-M/lib/libc_psr.so.1

1

243

0

/lib/libc.so.1

1

243

0

その他共有ライブラリ

9

246

0

/var/ld/ld.config

1

0

243

199,064

199,064

0

267

293

16

data/FA*/tagged*/*.dat
その他

4.2.2.5 再々分析結果 (2014 年 9 月 5 日)
ただ、上記の書き換えの結果、I/O 長の短い(9～128 バイト)write が激増してしまう、という新たな問題点が確認された。nawk 中の printf が、1 行 1 行 write システムコールを発生させてしまうために、新たな問題が起こってしまったようだ。そこで、上記の nawk 部分を、さらに以下のように書き換えてみた。
nawk '{
f=$0;
s=sprintf("<OTDoc><OTFile>%s</OTFile>\n",f);while((getline u<f)>0)
s=s u "\n";close(f);printf("%s</OTDoc>\n",s);}'1 行 1 行 write システムコールを発生させるのではなく、各 XML レコード毎にまとめて write をおこなうようにすることで、I/O 長を長くするよう工夫してみたのである。これに対しても、同様に truss ログを取得し、更新量の近い(約 20 万レコード)2014 年 9 月 5 日のデータベース更新ログを、同様の手法で分析した。そうしたところ、2014 年 4 月 15 日に較べ、ファイルへの write 回数は減ったものの、処理時間はむしろ増大するという結果となった(表 4.2.7 および表 4.2.8)。実際、ログの取得も 58 分を要し、体感的にも微妙に遅くなっていた。

45

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

表 4.2.7 2014 年 9 月 5 日 IO-Dock 分析結果(メタ I/O 系システムコール)
システムコール
実行回数
error 回数
処理時間
I/O 量

メタデータ

open(open64)

198,090265

3.17 sec-

close

198,7402

2.2 msec-

unlink19

40.73 sec

-

mkdir

1

0

0.1 msec-

rmdir

ファイル I/O

100.2 msec-stat(fstat64, etc)

1,273,052

1,624

18.66 sec-

read

1,065,598

089.34 sec

2.7GB

write

546,661

39,39363.73 sec

1.7GB

表 4.2.8 2014 年 9 月 5 日 IO-Dock 分析結果(ファイル I/O)
システムコール
ファイル
実行回数
処理時間
データ量

read
(TOP5)

kanseki.cat

570,20842.64 sec

1.40 GB32.86 MB/s

tagint.XX

47,46013.19 sec

388.79 MB

29.48 MB/skanseki.ip

47,411

11.48 sec

388.37 MB

33.83 MB/skanseki.i1

6

6.51 sec

194.18 MB

29.83 MB/skanseki.t1

1

5.20 sec

194.18 MB

37.34 MB/skanseki.cat

108

37.89 sec

467.11 MB

12.33 MB/s

203,357

3.25 sec

111.83 MB

34.41 MB/s

tagint.XX

23,7304.03 sec

194.39 MB

48.24 MB/skanseki.idx

23,7053.70 sec

194.18 MB

52.48 MB/skanseki.t1

23,7053.99 sec

194.18 MB

48.67 MB/skanseki.i1

23,705

3.56 sec

194.18 MB

54.54 MB/skanseki.ip

189,633

3.91 sec

194.18 MB

49.66 MB/s

tmpalldat
write(TOP5+α)

I/O 速度

4.2.3 考察
全国漢籍データベースの更新プログラムのファイル I/O 改善において、cat コマンドの繰り返しを nawk でまとめることにより、libc_psr.so.1 や libc.so.1 あるいは /var/ld/ld.config の open 回数を減らすことに成功し、その結果として、全体で 3 倍程度の高速化が実現できた。一方、nawk の printf の回数を減らすことで write 長を長くしても、I/O 回数を減らすことにはなるが、現実には高速化できず、むしろ遅くなっている。もちろん、これらは ZFS の実装や、あるいは nawk の現実の flush タイミングに依存している可能性は高いが、プログラムの改良におけるファイル I/O の改善に関しては、非常に示唆的だと考えられる。

4.2.4 まとめ京都大学人文科学研究所附属東アジア人文情報学研究センターのデータベース運用上、かなり大きな問題となっていた全国漢籍データベースの更新プログラムの「遅さ」が、IO-Dock を用いたファイル I/O 分析により、見事に改善された。特に、/var/ld/ld.config の ENOENT エラーが「遅さ」の一因だったという事実は、プログラムそのものをいくらチェックしても発見できないことであり、この分析手法の有用性の一端を示したと言える。

46

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.3 国立天文台天文データセンター
4.3.1 概要
4.3.1.1 システム概要
国立天文台ではまとまった計算機システムはなく、基盤ネットワークの上で、各プロジェクトがそれぞれの計算機システムを運用している。本章ではこの中で、天文データセンター[8]が大学研究者等の一般共同利用研究者に対しサービスを提供している多波長データ解析システムにおいて、いくつかのソフトウェアのストレージ利用状況をユーザの立場から調査した結果について報告する。
台内ユーザ

ＶＰＮ経由ユーザssh
対話型解析
サーバ高ｘ10

解析端末 x22

対話型解析
サーバ中 x16

ファイル(NFS)
サーバ x4ＮＡＳ(home)x2

ＮＦＳ(NFSv3)マウント

図 4.3.1 国立天文台天文データセンター多波長解析システムのユーザディスク構成
公開共同利用システム(多波長データ解析システム[9]）のユーザディスク構成を図 4.3.1 に示した。本システ
ムは 2014 年 12 月現在、ユーザ数 329 名である。サーバとして対話型 26 台（中性能 16、高性能 10 台)があり、これらサーバの作業領域としてファイルサーバ 4 台のディスクを NFS(NFSv3)マウントしている。ファイルサーバ
は、1 サーバにつき 16TB のストレージを 4 か 5 領域持っており、それが 4 台で合計～288TB である。この他、図にも示した作業用端末 22 台のほか、バッチ処理用システム（サーバ 8 台）もあり、これらすべてがファイルサー
バ 4 台の作業領域を NFS マウントする構成である。ネットワークは GB ethernet で構成されている。NFS 構成は
必ずしも高速でもなくてよい作業領域を大容量かつ安価に実現することを求めた結果であり、また NFSv4 ではな
い理由は、速度よりも安定性を求めたためである。ある程度以上高速な I/O が必要とされる解析作業には、各解析サーバの内蔵の作業領域ディスク(解析サーバ(高)は 16TB×1、解析サーバ(中)は 16TB×2)を利用することが想定されている。ユーザはネットワーク経由の場合も端末利用の場合も対話型サーバに ssh でログインし、解析作業を行うのが一般的なスタイルである。OS は測定時にはファイルサーバも含め、全て Redhat Enterprise Linux
Server 6.4 であった。2014 年 12 月現在は RHEL 6.5 である。

[8]
[9]



ファイルサーバ(NFSv3)



解析サーバ（高）

解析サーバ（中）富士通 PRIMERGY+富士通 ETERNUS DX80 S2 × 20
16TB(RAID6(7+2), 3TB 7200rpm NLSAS, ext3) × 4 or 5
富士通 PRIMERGY RX200 S7
メモリ：256GB (DDR3 1600 RDIMM 16GB × 16)
CPU：Intel Xeon E5-2690 (2.9GHz, 8core) × 2
富士通 PRIMERGY RX200 S7
メモリ：128GB (DDR3 1600 RDIMM 8GB × 16)
CPU：Intel Xeon E5-2690 (2.9GHz, 8core) × 2

http://www.adc.nao.ac.jp/
http://www.adc.nao.ac.jp/J/kaiseki_top.htm
47サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.3.1.2 システム健康診断結果概要
対話型解析サーバからファイルサーバの 1 領域へのアクセス性能を、SS 研大規模ストレージＷＧ作成の健康診断ツールで測定した。これはユーザ権限で通常運用中に測定したものであり、理想的な環境ではなく実運用でユーザの体感する性能を見ているものであると言える。

図 4.3.2 多波長解析システムのシステム健康診断結果（抜粋）
結果の一部を図4.3.2に示す。
メタアクセス性能およびRead性能はプロセス数に比例して性能が伸びているが、Write は逆にプロセス数に反比例している。これはメタアクセス・Read ではクライアントキャッシュ効果が良く出ているが、Write では sync を行っているためサーバ性能ネックが顕在している物と推察できる。なお、Write 性
能は最大で 70MB/s 程度である。これは GB ether の上限の 6 割程度しか出ていないが、この原因は不明である。
もしこれより大幅に性能劣化した結果が得られた場合は、何らかの不具合が発生している恐れがあると考えてよいであろう。これらの基礎データを踏まえ、次節以下のシステムコール分析を行った。

4.3.2 システムコール分析結果
4.3.2.1 実行環境
次節以降の実行プログラムは、4.3.1.1 で紹介した環境中の対話型解析サーバ（中）で実行した。大部分の読
み書きは、ファイル(NFS)サーバのストレージに対して行っている。これ以外に共有ライブラリの参照等で内蔵のシステムディスク、実行時のシェル環境設定ファイルの参照等でホームディレクトリのある NAS への I/O が発生しているが、これらは実行時間には影響しないと考えられる。また strace のログは、対象となる読み書きを行うファイルサーバとは異なるファイルサーバのストレージあるいは、ローカルストレージに対して書き出している。情報採取は一般ユーザが通常運用中に行っている。前節の健康診断結果と同様、理想的な環境ではなく実運用でユーザの体感する性能を見ているものであると言える。

48

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.3.2.2 実行プログラム概要
天文台のシステムにおいては、以下の 4 つの実行プログラムについて情報を取得した。
(1)saoimage-ds9
saoimage-ds9 (Joye & Mandel 2003)[10]は、スミソニアン天体物理観測所(SAO)が開発したソフトウェアであり、FITS(Flexible Image Transport System)[11]という天文業界でよく利用されるファイル形式のデータを、画像として表示したりする際に用いられている(図 4.3.3)。2014 年 12 月現在の最新バージョンは 7.3.2 であるが、測定時は 7.1 を用いていた。データ I/O 量としては、たとえば、10k×10k ピクセルで、1 ピクセルが 4 バイトの画像データは 400MB であるが、このようなサイズのデータの表示閲覧、
また部分拡大などは日常的に行われている。
かつ、このアプリケーションは対話型でインタラクティブに使われるため、ストレージ性能は操作性・体感に大きく影響する。
今回の調査では、少し大きめの 2.2GB のファイルの閲覧を行い、ストレージへのアクセスがどのように発生しているかの調査を試みた。

図 4.3.3 saoimage-ds9 の表示例

[10]
[11]

http://ds9.si.edu/
http://fits.gsfc.nasa.gov/fits_home.html

49

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書(2) ls の遅延
多波長データ解析システムでは、時々 ls の反応が遅くなるという報告がユーザから挙げられていた。この様子を確認するため、約 7000 ファイルを入れたディレクトリに対し、一時間おきに /bin/ls -ltr をかけた結果をモニタして、実行速度のバラツキを調べた。
(3) SWarp
SWarp(Bertin et al. 2002)[12]は、天球上を撮像した複数の FITS 画像を、較正された位置情報を元に繋ぎ合わせてかつ重ね合わせるソフトウェアウェアである。このソフト
ウェアを用いて、22 枚の800x800 pixel 程度（各2.1-2.3MB
程度)を 1 枚の 2400x3200 pixel 程度の(29MB)にする操作
において、I/O を調査した。図 4.3.4 には実際にこの重ね合わせを行った例を示している。
図 4.3.4 SWarp による重ね合わせ。左は 1 画像、右は重ね合わせ後(4)ユーザプログラム(plot5)
SM[13]は、UNIX 環境においてグラフ等の描画を行う機能を提供するサブルーチン群とそのフロントエンドソフト
ウェアであるが、このサブルーチン群を用いてデータをグラフ化してポストスクリプトに出力する自作ソフトウ
ェア(plot5)の I/O を、正常時と処理時間の遅い異常時を比較し調査した。

4.3.2.3 分析結果
(1)saoimage-ds9
IO-Dock 実行結果の一部を表 4.3.1-4.3.3 に示した。
表 4.3.1 saoimage-ds9 実行時の I/O システムコールの多いファイル※除外：SOCKET、標準入出力、共有ライブラリ、/proc、/var、/etc

[12]
[13]

http://www.astromatic.net/software/swarp
http://www.astro.princeton.edu/~rhl/sm/sm.html
50

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

表 4.3.2 saoimage-ds9 実行時の read システムコールの統計

strace の中には 2.2GB のファイル(Rtest.fits)の read に該当するものが見られなかった。本来は表 4.3.2 のread に表れてくるべきものである。この結果を詳細に調査したところ、saoimage-ds9 は mmap システムコール
を使い、open したファイルをメモリにマップして使っていることがわかった。
そして、この mmap 経由の I/O は、
strace では捕捉できないことが判明した。
また、この事例の初期の解析で、解析ツールの初期バージョンではソケットもファイル I/O として誤って解釈していたが、この点は最新バージョンではストレージへの I/O と、ソケットや FIFO は区別するように改良されている。
表 4.3.3 saoimage-ds9 実行時の mmap とソケットの統計

socket write
ファイル
SOCKET
SOCKET:/tmp/.X11-unix/X0

実⾏回数 成功
3,310 3,310
1,315 1,315

51

失敗 処理時間 IO量
00.9 ms 145 MB
00.2 ms 351 KB

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

(2)ls
表 4.3.4.1 ls 実行時の I/O 関連システムコールの統計（速い時）syscall
実行回数 error回数 処理時間[s]平均処理時間[s] 最少処理時間[s] 最大処理時間[s]
fcntl
1
0
0.000009
0.000009
0.000009
0.000009
read
14
00.000136
0.000010
0.000008
0.000016
write
129
0
0.002934
0.000023
0.000021
0.000038
stat
6902
0
0.071214
0.000010
0.000008
0.000034open
12
00.000347
0.000029
0.000010
0.000214
getdents
1200.000650
0.000054
0.000027
0.000065
close
19
00.000187
0.000010
0.000008
0.000019
fstat
13
00.000112
0.000009
0.000008
0.000011
statfs100.000011
0.000011
0.000011
0.000011
lseek
100.000009
0.000009
0.000009
0.000009
lgetxattr
20712
20712
0.249096
0.000012
0.000008
0.000055
lstat
13808
0
0.795326
0.000058
0.000010
0.000683

表 4.3.4.2 ls 実行時の I/O 関連システムコールの統計（遅い時）syscall
実行回数 error回数 処理時間[s]平均処理時間[s] 最少処理時間[s] 最大処理時間[s]
fcntl
1
0
0.000012
0.000012
0.000012
0.000012
read
12
00.000117
0.000010
0.000008
0.000016
write
129
0
0.003112
0.000024
0.000022
0.000041
stat
6902
0
0.075346
0.000011
0.000008
0.000961
open
12
00.038194
0.003183
0.000009
0.038064
getdents
1200.320007
0.026667
0.000048
0.163230close
18
00.000177
0.000010
0.000008
0.000016
fstat
13
00.000144
0.000011
0.000008
0.000042
statfs100.000011
0.000011
0.000011
0.000011
lseek
100.000008
0.000008
0.000008
0.000008
lgetxattr
20712
20712
5.545225
0.000268
0.000011
0.722723
lstat
13808
0
0.314374
0.000023
0.000009
0.113075

ls 実行の際、時間がかかった場合と平均的な時間の場合の IO-Dock の結果を表 4.3.2.1-4.3.4.2 に示した。
stat, open,getdents, lgetxattr, lstat の最少処理時間に大きな差はなかったものの、最大処理時間(表中では背景を色づけ)に大きな差が見られた。これらを詳細に調べた結果
17:03:08.401014 lgetxattr("XXXXX", "security.selinux", 0x1a90fb0, 255) = -1 EOPNOTSUPP (Operation not supported) <0.000013>
17:03:08.401145 lgetxattr("XXXXX”, "system.posix_acl_access", 0x0, 0) = -1 ENODATA (No data available) <0.722723>
17:03:09.123934 lgetxattr("XXXXX", "system.posix_acl_default", 0x0, 0) = -1 ENODATA (No data available) <0.000022>

図 4.3.5 strace の結果の中の lgetxattr が失敗していた部分の抜粋
図 4.3.5 に示すように、lgetxattr では、同じファイル（図中では XXXXX と略記)に対して、3 回拡張属性の取得を行っているが、全てエラーになっていたことがわかった。

52

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書(3)SWarp
表 4.3.5 SWarp 実行時の I/O 関連システムコールの統計
syscall
close
fstat
read
write
lseek
mmap
stat
munmap

実行回数 error回数 処理時間[s]平均処理時間[s] 最少処理時間[s] 最大処理時間[s]154
01.657865
0.010765
0.000008
0.304729151
00.001917
0.000013
0.000008
0.000065
3369
00.090412
0.000027
0.000008
0.0034874782
00.182544
0.000038
0.000015
0.002006
276
00.002795
0.00001
0.000007
0.000063
172
00.002198
0.000013
0.000009
0.00006544
140.000527
0.000012
0.000008
0.000029
156
00.005997
0.000038
0.000011
0.000388

表 4.3.6 SWarp 実行時の I/O システムコールの多いファイル(open)

ファイル名
実行回数 エラー回数 処理時間[s]mfl_*_resamp.fits
46
00.024778
mfl_*_resamp.weight.fits
46
00.009031
共有ファイル等
45
340.000506
coadd.fits
100.000192
coadd.head
1
10.000108
coadd.weight.fits
100.000148
mfl_b.lis
100.000368
swarp.conf
1
0
0.000278
swarp.xml
100.002003
mfl_*.fits
46
00.008968
mfl_*.head
23
23
0.001898
表 4.3.7 SWarp 実行時の I/O システムコールの多いファイル(close)
ファイル名
実行回数 エラー回数 処理時間[s]mfl_*_resamp.fits
46
0
0.526696
mfl_*_resamp.weight.fits
46
00.520030
共有ファイル等
11
00.000123
coadd.fits
100.304272
coadd.weight.fits
100.304729
mfl_b.lis
100.000010
swarp.conf
1
0
0.000011
swarp.xml
100.001311
mfl_*.fits
46
00.000683
表 4.3.8 SWarp 実行時の I/O システムコールの多いファイル(read)

ファイル名
実行回数
処理時間[s] 処理量[byte]
mfl_*.resamp.fits1462
0.032339
46,903,680
mfl_*.resamp.weight.fits1462
0.033042
46,903,680
mfl_*fits431
0.024897 103,003,456
mf._b.lis
20.000020
308
swarp.conf
2
0.000023
5,031
共有ファイル等
100.000091
7,193

53

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

表 4.3.9 SWarp 実行時の I/O システムコールの多いファイル(write)

ファイル名
実行回数
処理時間[s] 処理量[byte]
mfl_*.resamp.fits
1462
0.061972
46,903,680
mfl_*.resamp.weight.fits
1462
0.056894
46,903,680
標準エラー
70.010741
301
coadd.fits
925
0.026552
30,291,840
coadd.weight.fits
925
0.026356
30,291,840
swarp.xml
10.000029
21,103
SWarp の場合、表 4.3.5 - 4.3.9 に示したように、処理時間が長いのは close システムコールであり、SWarp が最終出力として作成した画像(coadd.fits)、その各画素での重み(coadd_weight.fits)、および入力した 22 ファ
イルとリファレンスを、coadd.fits の座標に合わせて再サンプリングした画像(mfl_*_resamp.fits)とその重み(mfl_*_resamp.fits)という、新規に SWarp が作成したファイルの close が I/O 関連の処理時間の 8 割強を占めていた。一方で write では 1 割分程度しか処理時間を使っていない。特に最終出力ファイル 2 つの一方に絞って各システムコールの処理時間をまとめたものが表 4.3.10 である。ここでも全体と同じ傾向がみられる。
出力ファイルに対する、I/O 量や、書き込み位置オフセットの時間変化を図 4.3.6 に示す。シーケンシャルに書き込まれており、処理速度から恐らくはキャッシュに乗っているであろうことがわかる。
表 4.3.10 SWarp 出力ファイル(coadd.fits)に対する、I/O システムコールの統計
syscall
close
fstat
write
open

平均処理時間[s] 最少処理時間[s] 最大処理時間[s]実行回数 error回数 処理時間[s]100.304272
0.304272
0.304272
0.304272
100.000010
0.000010
0.000010
0.000010
925
00.026552
0.000029
0.000020
0.000078
100.000192
0.000192
0.000192
0.000192

図 4.3.6 SWarp 出力ファイル(coadd.fits)への write システムコールの挙動
なお、この出力ファイル(coadd.fits)について言えば、28.9MB の全書き込み処理(open+write+close)にかかった時間が 0.30 秒だと考えて 96MB/s であり、健康診断で得た 70MB/s より 40%ほど良い性能が出ている。

54

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書(4)plot5
表 4.3.11.1-4.3.11-2 に、IO-Dock による正常時と異常時のシステムコールの統計を示した。背景の色付けで示したように、異常時は、open/close に非常に多くの処理時間がかかっていたことがわかる。また、最大処理時
間が処理時間とほぼ等しいことから、最大処理時間を要した 1 回の処理が平均を押し上げていることが推測される。具体的にどのファイルへの open/close に処理時間がかかっていたか調査したところ、40 バイト程度の動作設定ファイルのopen/closeが特定の回だけ直後の同様の処理と比較して大きな処理時間となっていたことがわかった。この時間がかかった open/close とその直後の通常の open/close の strace のログを図 4.3.7 - 4.3.8 に示した。
表 4.3.11.1 plot5 実行時の I/O システムコールの統計(正常時）syscall
read
write
open
writev
close
fstat
lstat

平均処理時間[s] 最少処理時間[s] 最大処理時間[s]実行回数 error回数 処理時間[s]992
00.008003
0.000008
0.000006
0.000034
335
00.003771
0.000011
0.000008
0.000094
246
1450.007349
0.000030.000007
0.000186
435
00.008070.000019
0.000014
0.000087107
00.001063
0.00001
0.000006
0.0001186
00.000812
0.000009
0.000006
0.000075
2
10.000016
0.000008
0.000008
0.000008

表 4.3.11.2 plot5 実行時の I/O システムコールの統計(異常時）syscall
read
write
open
writev
close
fstat
lstat

num

err
984
336
246
435
107
86
2

0
0
145
0
0
0
1

処理時間[s]
平均処理時間[s] 最少処理時間[s] 最大処理時間[s]0.008111
0.000008
0.000006
0.000052
0.003671
0.000011
0.000008
0.000104
13.966408
0.056774
0.000007
13.936576
0.008841
0.000020.000015
0.000118
1.958181
0.018301
0.000007
1.939770.001254
0.000015
0.000007
0.0002410.000019
0.00001
0.000009
0.00001

12:08:20.010048 open("plot.cfg", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5 <13.936576>
12:08:33.946722 fstat(5, {st_dev=makedev(0, 55), st_ino=485802001, st_mode=S_IFREG|0644, st_nlink=1, st_uid=11160,
st_gid=12000, st_blksize=32768, st_blocks=0, st_size=0, st_atime=2014/01/03-15:47:22, st_mtime=2014/01/04-12:08:20,
st_ctime=2014/01/04-12:08:20}) = 0 <0.000241>
12:08:33.947094 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0764626000 <0.000061>
12:08:33.947247 lseek(5, 0, SEEK_SET)= 0 <0.000058>

12:08:33.947421 write(5, "all3.dat1\n$1==88&&($2<=0.95)\n$9\n"..., 42) = 42 <0.000046>
12:08:33.947509 close(5)= 0 <1.939770>

12:08:35.887369 munmap(0x7f0764626000, 32768) = 0 <0.000059>

図 4.3.7 plot5 実行時、異常な open/close 前後の strace ログ抜粋
12:08:35.887519 open("plot.cfg", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5 <0.005942>
12:08:35.893554 fstat(5, {st_dev=makedev(0, 55), st_ino=485802001, st_mode=S_IFREG|0644, st_nlink=1, st_uid=11160,
st_gid=12000, st_blksize=32768, st_blocks=0, st_size=0, st_atime=2014/01/03-15:47:22, st_mtime=2014/01/04-12:08:35,
st_ctime=2014/01/04-12:08:35}) = 0 <0.000011>
12:08:35.893618 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0764626000 <0.000010>
12:08:35.893651 lseek(5, 0, SEEK_SET)= 0 <0.000008>

12:08:35.893718 write(5, "all3.dat1\n$1==88&&($2<=0.95)\n$9\n"..., 42) = 42 <0.000019>
12:08:35.893776 close(5)= 0 <0.001514>

12:08:35.895320 munmap(0x7f0764626000, 32768) = 0 <0.000012>

図 4.3.8 plot5 実行時、正常な open/close 前後の strace ログ抜粋

55

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.3.3 考察
(1) saoimage-ds9
前節で述べた通り、mmap 経由の I/O は捕捉できていない。本事例ではこの最大のファイル I/O を捕捉できなかったため、プログラムの I/O の効率の吟味は行うことができなかったが、本ＷＧで検討しているツールの制限
事項（制約）を検知したという意味で有意義であった。
(2) ls の遅延
まず解析より明らかになったことは、lgetxattr システムコールが全部エラーになっていたことであった。これは本解析システムの設定の問題で、ACL(Access Control List; アクセス制御リスト)機能を OS が未サポートにもかかわらず、noacl オプションをつけずマウントしていたことにあったことが判明した。この問題点は当該システム管理者に連絡し、現在は改善されている。
次にわかったことは、大きな遅延が発生しているのは、ファイルサーバ側に ACL を問い合わせに行って読み出しに時間がかかっている部分だということであった。ここで 0.7 秒もかかるケースが 2 例あった。一方これ以外にも getdents で1 秒かかるケースもあった。
この部分は通常は 15-20m 秒程度で、速い時は数十 μ 秒で終了する。

図 4.3.9 NFS とキャッシュ構成の概念図
十数 m 秒と十数 μ 秒の違いはクライアントキャッシュにヒットしたかどうかの違いと考えられる。
概念図を図
4.3.9 に示した。しかし、これだけでは数百ｍ秒の遅れは説明できない。更に分析を行うためには、ファイルサーバ側の OS の統計情報が必要である。一例に関しては NFS 高負荷による Disk Busy 状態だと推測されるが、その他のケースでも同様の遅れは見えており、これが Disk Busy だったのかどうかは不明である。
またその後、本調査と別の管理者側の調査として、このような遅延はファイルサーバ側でカーネル周りで Busy 状
態になり、割り込みが入れなかったせいではないかと推測された。この点の設定変更が行われた結果、図 4.3.10に示すように、3 割程度の速度向上と安定化が見られた。

図 4.3.10 ls の所要時間。1 時間毎の測定結果。改善前(青)と改善後(赤)56サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書(3) SWarp
write の処理時間が短く、close で時間がかかっていることから、write は NFS クライアント側でのキャッシ
ュへの書き込みで処理が終了し、一方 close ではキャッシュの掃き出しコストが見えているのだと推測される。
これはデフォルトの cto(close-to-open)から、nocto にマウントオプションを変更することで復帰時間の改善は可能だが、nocto の場合、他のクライアントから読む場合に不整合が生じうるなど副作用も大きいと考えられる
ため、現行の運用が妥当である。その他、ファイル I/O はシーケンシャルであり、速度もトータルで健康診断結
果以上の値を出しており、適切である。
(4)ユーザプログラム(plot5)
異常に処理時間がかかったケースは、(2)ls で述べた、ファイルサーバ側の問題が絡んでいた可能性があり、偶然割り込みに失敗してしまったケースでのみ、サーバでの待ちが長くなったのだと解釈すれば説明はつく。しかし本当に何が起きていたかに関しては、strace の情報だけでは不十分であり、サーバおよびクライアントでの統計情報を取得し解析する必要がある。
なお、ファイルの open/close の回数を減らすことで、このような問題の発生頻度を下げることが可能である。本
プログラムは同じファイルに対して open/write/close を繰り返しているため、open/close を 1 回にしてファイ
ルデスクリプタを使い続けるようにすれば改善が見込まれる。

4.3.4 まとめ
国立天文台の共同利用計算機で一般ユーザとしての利用例として、4 つのケースについての IO-Dock を用いた解析を試みた。1 つのケース(SWarp)には特に問題が見られないことが示された。1 つのケース(ls)については解析結果に基づき改善提案を行うことができ実際に改善が見られた。この改善でもう 1 つのケース(plot5)も改善されていると考えられる。これらは、IO-Dock の有用性、特に一般ユーザ権限での実行においても有益な場合があることを示した例であるといえる。最後の 1 つのケース(saoimage-ds9)では、strace は mmap に基づく I/O を捕捉できないという構造上の問題から十分な解析は行えなかった。これは今後の検討課題である。また、IO-Dock
のみによる解析では必ずしも問題の原因特定にまでは至らないケースがあり、計測時のサーバ、クライアントの統計情報や、プロセスの稼働状況などの情報も併せて取得しておくことが重要であることが再認識された。

57

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.4 東京大学宇宙線研究所附属神岡宇宙素粒子研究施設
4.4.1 概要
スーパーカミオカンデは、さまざまなニュートリノや陽子崩壊事象を観測するため、24 時間 365 日常時観測を続けている。このため、観測データを全て記録し、さらにはこのデータを用いたさまざまな研究を行うために用意された専用データ解析用計算機システムも、観測に合わせて常時安定して稼動することが必須となる。この計算機システムの利用目的・利用方法は大きく次の四つに分けることができる。一つ目はスーパーカミオカンデ検出器から得られたデータをディスクおよびテープに記録するため。二つ目は、得られたデータを常時継続的に一次解析することで、検出器の状態監視、超新星ニュートリノなどの突発事象の検出をリアルタイムで行うため。
三つ目は、さまざまなニュートリノ反応や陽子崩壊が実際にはどのように観測されるかというシミュレーション
データを大量に作成するため。四つ目は、実験データならびにシミュレーションデータを用い、ニュートリノの性質を詳細に調べる研究、陽子崩壊などごく稀にしか起こらないと考えられる現象の研究などを行うための解析のためである。
特に、第一、第二の目的である、スーパーカミオカンデのデータを常時確実に蓄積し、これらをリアルタイムに常時モニターし続けるためには、計算機システム全体が安定して稼動することは必須となる。

4.4.1.1 システム概要
スーパーカミオカンデ実験用計算機システムは、データ収集用のシステムと解析用システムに大別される。解析用としては、
ユーザ用ログインノードと計算ノードをあわせ 1716 の CPU コアを持ち、これらが FEFS を用いた、3PB の大容量磁気ディスクシステムに接続される形となっている。詳細を表 4.4.1、4.4.2 に示す。
表 4.4.1 スーパーカミオカンデ実験用計算機システム演算処理装置概要
用途
CPU
メモリ
ノード数
データ解析用計算機
Xeon 3.46GHz
24GB/ノード13（ログインノード）
6 cores x 2CPU
データ解析用計算機
Xeon 3.46GHz
24GB/ノード116（計算用）
6 cores x 2CPU
リアルタイム処理用計算機
Xeon 3.46GHz
24GB/ノード1（ログインノード）
6 cores x 2CPU
リアルタイム処理用計算機
Xeon 3.46GHz
24GB/ノード
12（計算用）
6 cores x 2CPU
ジョブ管理ノード
Xeon 2.26GHz
12GB ノード
6
2CPU
制御ノード
Xeon 2.26GHz
12GB/ノード32CPU
表 4.4.2 スーパーカミオカンデ実験用計算機システムディスク装置概要
名称
ディスク実容量
ファイルシステム
大容量磁気ディスク I
1368TB
FEFS
大容量磁気ディスク II
1378TB
FEFS
ホームディレクトリサーバ
12.5TB
解析用計算機システムはリアルタイム処理用とデータ解析用にわかれ、それぞれ独立のジョブ管理システムが稼動している。これは、ジョブ管理システムにユーザが過大な負荷をかけてしまったとき、リアルタイム処理に影響を及ぼすことが過去にあったためである。若干の無駄もでてしまうが、リアルタイム処理の安定性を最優先し、現在のシステムでは完全に独立させることとした。

58

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

検出器から解析用計算機にまで流されるデータは、一日あたり 900GB 程度となっている。解析用計算機システ
ムでは、まず検出器から届いたデータファイルを、解析時に用いるファイル形式に変換する。さらに、一次解析を行うことで、事象のエネルギーが極めて低い事象とノイズや明らかな背景事象を弁別する。一次解析によりノ
イズや背景事象と判別されたもの以外、全てのデータをディスクとテープに記録する。ディスクに記録されたデータに対しては、さらに精度の高いニュートリノ事象・陽子崩壊事象判定ソフトウェアをすぐに適用し、その結果も常時ディスクに記録する。この解析結果は、後にニュートリノや陽子崩壊事象の研究に用いられるほか、結果を常時シフトがモニターすることで、検出器の安定性を把握、異常の早期検出のためにも用いられる。
解析に用いられるプログラムやシミュレーションデータ生成プログラムは、シングルスレッドのものが大半であり、基本的にはデータの入出力時間よりも計算時間が長くなっている。このため、同一のプログラムを独立プ
ロセスとして同時に多数走らせることで、全体の処理時間をという方法が取られる。このとき、ほとんどの場合は各プロセスが違うファイルにアクセスして処理を行っている。よって、ファイルシステムに対する要請の一つとして、CPU コア数分の独立したプロセスからファイルシステム内の多数のファイル、最大では CPU コア数以上の異なるファイルにアクセスが行われた場合でも極端に性能が落ちることがなく、安定して動作すること、というものが出てくる。すでに述べたようにジョブ管理システムや処理ノードなど CPU については二系統にわかれているが、ファイルシステムについては単一であるため、解析プログラムが大量に走った場合等に、ファイルシス
テムへのアクセス速度が非常に遅くなったり、動作が不安定になると、リアルタイムで行っているデータ変換、記録などの処理が滞ってしまう。このため、ファイルシステムの安定性は本システムの中でも最も優先度の高いものとなっている。

4.4.1.2 システム健康診断結果概要
ファイル健康診断ツールを用いた診断結果を図 4.4.1 に示す。実際の運用時においても 1MB のブロックで書き込んだ場合はシングルプロセスで 200MB/s 程度の速度が安定して出ている。また、多重アクセス時にも安定しており、メタデータ性能も当初の設計どおりの性能を出している。2012 年の稼動から、ハードウェア障害によって若干の停止はあったが、ソフトウェア障害による停止は発生しておらず、非常に安定して稼動している。

図 4.4.1 スーパーカミオカンデ実験用計算機 ファイルシステム 健康診断結果

4.4.2 システムコール分析結果
4.4.2.1 実行環境
今回は、
比較I/Oの多いプログラムをデータ解析用計算機のログインノードで走らせた。
実行時の OS は Red Hat
Enterprise 5 である。また、他のプログラムからの干渉を減らすため、試験時に同一ノード上で I/O 負荷の高いプロセスが走っていないことを確認して行った。

59

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.4.2.2 実行プログラム概要
今回は実験データのファイル形式を変換するプログラムについて、システムコール分析を行った。このプログ
ラムは CPU 資源が大きく必要となる処理がほぼないため、その動作速度はディスク I/O 性能で決定されると予想されるが、プログラムの実行に要する時間がディスク I/O 速度から予想されるよりもかなり長いことがわかっていたため、この原因を探るため分析を行った。

4.4.2.3 分析結果分析を行うにあたっては、標準的な大きさである約 500MB の入力ファイルを処理、変換後に 300MB のファイルが出力した場合についての解析を行った。
まず、ファイル I/O についての分析結果が表 4.4.3 および 4.4.4 となる。今回の試験で用いた入力ファイルの大きさは 500MB であり、処理にはファイルを 1 度だけ読みこめばよいのだが、実際にはファイルサイズの 50 倍である 25GB の入力があり、読み込みの合計時間が 35 秒となっていることがわかった。さらにファイルのアクセス
位置を操作するための lseek が大量に発行され、この処理にも 25 秒以上費やしていることがわかった。
表 4.4.3 システムコール分析結果（リード・ライト処理関連）
システムコール
read(全63ファイル中Top５)

ファイル

実⾏回数

処理時間 データ量

event_run071482.000010/usr/local/sklib_g77/root_v5.28.00b/etc/system.rootrc/usr/local/sklib_g77/root_v5.28.00b/include/RtypesCint.h/usr/local/sklib_g77/root_v5.28.00b/etc/plugins/TSystem/P020_TDCacheSystem.C/tmp/tmpfpNdvMS

3,092,219
73
6
235.0 sec 25.4 GB 726 MB/s
45 us 24.2 KB 538 MB/s
21 us
4.2 KB 199 MB/s
32 us
1.3 KB
42 MB/s
9 us
1.2 KB 128 MB/swrite
(全9ファイル中Top５)

rfm_run071482.000010.root/tmp/tmpfpNdvMS/tmp/tmpfuUpPTV/tmp/tmpf9tSf1Y/tmp/tmpfuhiHkD

401
1
1
1
1

329 ms
15 us
13 us
14 us
21 us

IO速度

312 MB 947 MB/s
1.2 KB77 MB/s
1.0 KB77 MB/s82 B 5.9 MB/s
44 B 2.1 MB/s

表 4.4.4 システムコール分析結果（ディスク I/O 処理関連）
システムコール
メタアクセス open
close
unlinkstat
ファイルIO read
write

実⾏回数
error回数
190
114
80
0
8
0
2,491
124
3,092,335
0
427
0

その他

4,638,810

lseek

0

処理時間
IO量
備考
27.7 ms
1.21 ms
0.06 ms
38.0 ms
35.0 sec 25.4 GB ほとんどが"event_run071482.000010"へのread
329 ms 312 MB ほとんどが"rfm_run071482.000010.root"へのwrite
25.6 sec- ほとんどが"event_run071482.000010"へのlseek

図 4.4.4 をみると、リード自体は 8 kB/block と小さめのブロックサイズで行われているが、図 4.4.2 でわかる
とおり、40 MB/s から 90 MB/s の速度が出ている。書き込みは、一定の処理が終わった時点でまとめて行われているが、図 4.4.4 をみると、ブロックサイズは数 kB から数 MB と大きなばらつきがある。しかし、キャッシュが有効に働いているためか非常に高速で、表 4.4.4 からわかるとおり、330ms 程度に収まっている。

Read

MB / sec

100
80
60
40
20
0
0

50

100

150

200

250

300

Elapsed time [sec] (Δ=1sec)

図 4.4.2 システムコール分析結果（リード速度の時間変化）

60

350

400

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

Write

MB / sec

20
15
10
5
0
0

50

100

150

200

250

300

350

400

Elapsed time [sec] (Δ=1sec)

図 4.4.3 システムコール分析結果（ライト速度の時間変化）

0B

15

read
write

1B
~2 B
~4 B

9

~8 B
~16 B
~32 B

5 11
5 21
15
1
3 18
5
46
1
11
1
22
3

~64 B
~128 B~256 B

IO⻑

~512 B
~1 KB
~2 KB
~4 KB
~8 KB
~16 KB~32 KB~64 KB~128 KB~256 KB~512 KB
~1 MB

1

~2 MB
~4 MB
~8 MB

1

3,091,842

6
126
8
19
4
4371
72 190
2
18
54
45
17
10
9
33

100

10,0001,000,000

図 4.4.4 システムコール分析結果（リード、ライト時のブロックサイズ分布）

61

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.4.3 考察
解析結果から、本プログラムでは lseek の実行回数が非常に多く、同じデータを何度も読み込んでいるため、リソースを無駄にしていることが判明した。試験したプログラムを確認すると、データ読み込み部では、ヘッダー読み込み
ヘッダー解釈lseek でヘッダー位置までファイルポインタを戻す
ヘッダーを含めた全データを読み込みという順序で処理が行われていた。このため、バッファリングがうまく働かず同一データを複数回読みこむことになっていたようである。そこで、予め読み込んだヘッダーを、全体を読み出すバッファにコピー、ヘッダー部を除いた残りのデータだけを次の処理で読み込むことで無駄を省くことができる。
この変更を行ったプログラムを用い、再度解析した結果を表 4.4.5 に示す。当初の試験は試験は Red Hat
Enterprise 5 で行っていたが、この試験は Red Hat Enterprise 6 を用いた。
（なお、Red Hat Enterprise 6 では lseek の扱いが大幅に改良され、この変更をおこなわなくても性能の改善がみられていた）
表 4.4.5 システムコール分析結果（ディスク I/O 処理関連）
システムコール
open
メタデータ
close
unlink
ファイルIO
その他

実行回数 error回数
332
244
93
0
8
0

修正前
処理時間
14.1ms
1.4ms
0.1ms

IO量

実行回数 error回数
374
286
93
0
8
0

修正後
処理時間
40.6ms
1.5ms
0.3ms

IO量
-

read

3,167,103048.0sec

26.0GB 1,583,929

025.7sec

13.0GB

write
lseek

353
4,750,841

03399.2ms
46.1sec

317.9MB353- 3,167,3600
3386.0ms
31.0sec

317.9MB-ここからわかるように lseek の回数が 2/3 程度に削減され、ファイル読み込み量も以前の半分となり、読み込
み処理時間は約 50%に減らすことができた。今回の変更ではプログラム中の明示的な lseek はほぼ全て削除したが、まだ多く呼びだされている。この理由を profiler を用いて調べたところ、プログラム中で使われている
ifstream の tellg が lseek を呼んでいることがわかった。よって、現在は tellg も使わないような変更を行う
ことを検討している。

4.4.4 まとめこのように、lseek などユーザがあまり気にせず使う関数により、プログラムの速度が遅くなる、システムに予想外の負荷をかけるといった問題を見つけるのはなかなか容易ではないが、今回の解析ツールを用いることで、この問題をはっきりと認識し、より効率的にシステムを用いることが可能になった。さらに、ユーザが明示的に関数を使っていない場合にはその原因探求がさらに難しくなるが、システムコール分析によってヒントが与えられることによってその調査の労力が軽減されることがわかった。

62

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.5 理化学研究所
4.5.1 概要
4.5.1.1 システム概要
理化学研究所(以下、「理研」)情報基盤センターではスーパーコンピュータ・システムを中核として、各種サー
バやネットワークなどの ICT によって、理研の研究者の活動を支援する多様な機器を運用している。現行スーパ
ーコンピュータ・システム(RICC:RIKEN Integrated Cluster of Clusters)は、本年度中(2014 年度)にサービスを停止し、次年度からは新システムの稼働を予定している。
RICC システム(図 4.5.1)は 2009 年 8 月から運用から開始したスーパーコンピュータ・システムで、演算システ
ムとして超並列 PC クラスタシステム、
多目的 PC クラスタシステムおよび大容量メモリサーバシステム(理論ピー
ク性能として、CPU:108TFLOPS、GPU:93TFLOPS(SP)、MDGRAPE-3:64TFLOPS)、ストレージとして 2 システム(ディスク:550TB、テープ:4PB、そのうち 2PB を利用)ファイルシステムには QFS+SRFS、テープマネジメントソフトウェ
アには HPSS を用いている。それらを繋ぐネットワーク(InfiniBand DDR、10GbE)から構成されている。本システ
ムは理研の幅広い研究分野のユーザをサポートするために、様々な計算資源を組み合わせた構成になっている。
ストレージ・システムについては、RICC ではディスク・ストレージ上のファイルへのダイレクト・アクセスとステージングの2通りの方式を混成して利用しており、超並列PCクラスタのバッチ運用部分はステージング運用、
インタラクティブ運用部分はダイレクト・アクセスと多目的 PC クラスタおよび大容量メモリサーバに関してはダ
イレクト・アクセスとなっている。データアクセス系の構成、データパス、帯域、台数などを図 4.5.2.2 および図4.5.2.3に示す。
図4.5.2.3の帯域はRAID装置からファイルサーバまでの帯域はバランスが悪く感じられるが、実際には RAID 装置単体には FC の帯域を埋める能力はなく、10GB/s 以上程度の実効性能を考慮している。RAID
装置の実効能力を設計値に用いたバランスの構成となっている。

図 4.5.1 RICC システム全体構成
RICC は利用者環境としてフロントエンドシステムを備える。しかし、フロントエンドで作業している際には、利用者からは基本性能に見合う性能が出ていないように見えることがある。また、レスポンスの低下がひどい場
合があり、レスポンスが低下した際に一番ストレスが高くなるというクレームがある。利用者の利便性を考えた
場合、ファイルシステムの健全性とは、利用者が居ない凪状態のシステム性能を提示することと同時に、ある時間毎のファイルシステムの性能およびレスポンスの時間経緯を効果的に測定し、利用者に提示する方法を考える必要があると考えられる。
本稿では、RICC のみを対象とするのではなく、より広い意味で利用者環境におけるストレージおよびファイル
システムの利用状況のレポート・分析および実状態のモニタリングを行える仕組みの構築を主眼とし、準備段階
63サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

として、現行の機器やアプリケーションによる考察ではなく、試験的に利用しているサーバや利用者環境でのファイルサーバおよびファイルシステム評価に利用できないか検討しているベンチマーク・プログラムを用いることとした。

4.5.1.2 システム健康診断結果概要
参考までに、RICC でのシステム健康診断結果の概要を示す。診断クラスは L であり、測定時間は約 1 時間 30分である。結果としては、帯域特性は非常に素直なデータであるが、メタデータアクセスの多重実行時にレスポンス低下が見られた。この結果が上記のレスポンス低下につながっているものと考えられる。
健康診断時に出ている状況は基礎性能を示すものとして重要であるが、実際に利用者が作業中に感じる感覚的
性能や実際に得られる性能との乖離はかなりあるものと推測される。

図 4.5.2.1 大規模データ転送

図 4.5.2.2 データ量一定(1GB)

図 4.5.2.3 データ量一定(100MB)
メタデータアクセス(ディレクトリ)

1000000
1000001000

10000
File creation
File removal
File stat

100

1000
100

10
10
1

10000

5

10

50

100

500

50プロセス以
上で頭打ち100000

1000

10000
100

Directory creation
Directory removal
Directory stat

プロセス数

1000
100

10

10
1
1

1000

10000000
1000000

1

1
1

5プロセス
時のみ突出

stat(1秒あたりの操作数)

50プロセス超で性能劣化

stat(1秒あたりの操作数)

10000

10000000

creation/removal(1秒あたりの操作数)

creation/removal(1秒あたりの操作数)

メタデータアクセス(ファイル)
プロセス数に
比例して増

5

10

50

100

500

1000

プロセス数

図 4.5.2.4 メタデータアクセス(ファイル)

図 4.5.2.5 メタデータアクセス(ディレクトリ)
64

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

4.5.2 システムコール分析結果
4.5.2.1 実行環境
本分析において用いたシステム環境およびソフトウェア環境を示す。システム環境は 1 台のサーバ上でソフト
ウェア環境を構築してプログラムを実行した。
・ ハードウェア
CPU：Core i7 3.0GHz ×1
Memory：32GB, DDR3
RAID card：MegaRAID (512MB DDR2)
Storage：1TB, SATA-II SSD(256GB)×4, RAID0・ ソフトウェア
OS：CentOS 5.4
Filesystem：ext4
Benchmark software：Filebench 1.4.9.1
ストレージ構成は、SSD 4 台を RAID-0 で接続したシステムを用い、RAID カード上に 512MB のキャッシュを要す
る構成である。I/O 帯域は 1MB ブロックの Direct Read/Write 双方で 1GB/s 以上を達成した。

4.5.2.2 実行プログラム概要
ベンチマークソフトウェアとして Filebench を用いた。Filebench は通常利用する bonnie、dd、IOZone などのように決められた性能を測定するのではなく、ファイルシステムのパフォーマンスを実際の利用形態を模した
workload という形で測定できる。今回は複数スレッドにそれぞれ同じ処理を実行させる形態としたが、様々な
workload を定義してランダムに実行して、その平均値をとるといった利用者が実感している実環境に即したベンチマークが出来ないか試行している。本稿では、以下の workload（SPECsfs 相当）を用いて測定を行った。

set $dir=/tmp
set $nfiles=10000
set $meandirwidth=20
set $meanfilesize=128k
set $nthreads=10
set $iosize=1m
set $meanappendsize=16k
define fileset name=bigfileset,path=$dir,size=$meanfilesize,entries=$nfiles,dirwidth=$meandirwidth,prealloc=80
define process name=filereader,instances=1{
thread name=filereaderthread,memsize=10m,instances=$nthreads{
flowop createfile name=createfile1,filesetname=bigfileset,fd=1
flowop writewholefile name=wrtfile1,srcfd=1,fd=1,iosize=$iosize
flowop closefile name=closefile1,fd=1
flowop openfile name=openfile1,filesetname=bigfileset,fd=1
flowop appendfilerand name=appendfilerand1,iosize=$meanappendsize,fd=1
flowop closefile name=closefile2,fd=1
flowop openfile name=openfile2,filesetname=bigfileset,fd=1
flowop readwholefile name=readfile1,fd=1,iosize=$iosize
flowop closefile name=closefile2,fd=1
flowop deletefile name=deletefile1,filesetname=bigfileset
flowop statfile name=statfile1,filesetname=bigfileset}}

図 4.5.1 ワークロードスクリプト65

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

workload を要約すると、10 スレッドでファイルあたり以下の同一の処理を一定回数繰り返し行う。総ファイル数は 10000 ファイルとした。
1. ファイル作成(&Open)
2. ファイル書き込み
3. ファイル Close
4. ファイル Open
5. ファイル追記
6. ファイル Close
7. ファイル Open
8. ファイル読み込み
9. ファイル Close
10. ファイル削除
11. ファイル Stat
これらの動作をおよそ 10 分間の実行時間を目安に実行したが、実経過時間はおよそ 20 分弱だった。しかし、Strace で実行した場合、2 時間ほどの時間を要した。ログファイルとしては 41.6GB（約 600 万イベント）となり、かなり大規模なログファイルであり、解析にかなりの時間を要した旨の報告があり、ご尽力頂いた富士通の酒井さんにお礼を申し上げる。ただ、今回の計測では、測定対象のファイルシステムとログ書き込みのファイルシス
テムが同一であったため、その影響がどの程度かの切り分けが出来ないことが反省点である。

4.5.2.3 分析結果
結果は想定通りに、一定の Open/Write/Append/Read/Close/Stat を繰り返すサイクルとなり、全ての動作はおよそ一定時間内で繰り返される挙動となった。
図 4.5.2、
図 4.5.3 に本ベンチマークでの全 Read/Write 処理の I/O
時間および I/O 長をプロットした。

図 4.5.2 各 Read/Write 処理での I/O 時間

図 4.5.3 各 Read/Write 処理での I/O 長

57 秒

図 4.5.4 Read 特異点
66

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

227 秒

図 4.5.5 Write 特異点
ただし、図 4.5.4、図 4.5.5 で見られるように、I/O 処理に通常の 10000 倍を超える時間がかかる特異点が散見される。

4.5.3 考察
今回の解析実行で明らかにしたポイントは、個々のアプリの特性解析ではなく、もっと大きな枠組みとして、
ストレージ・システムとファイルシステムが実際に使われているような環境において、定点観測を行う環境構
築した際に用いる速度観測プログラムの挙動をStraceなどのトレースを用いてどの程度トレースできるかという点にあった。
解析内容として、特異点が数カ所見られるが、概ね想定通りの挙動を示していた。ただし、Starce の結果だ
けでは、特定のシステムコールが全ての点で遅いなどの特性を表さない限り、特異点での性能低下は本当に何が原因なのははわからない。しかし、この点を追求するのは、本稿の趣旨でもこのプログラムの実行用途にも合致しないため取り残すが、一定範囲内で実行され、何か問題があれば、挙動に現れるであろうことは確認できた。
また、今回はベンチマーク・プログラム(利用者アプリ相当)に直接 Strace を実行している。利用者アプリに Strace を実行するのは本当に最後の手段であり、ユーザが日常的に使うには無理があるが、管理者がアプリの挙動を解析するには有効な技術と考えられる。この技術の前提は、利用者アプリの挙動を解析するために管理者側が利用することが前提となるだろう。
しかし、本来は利用者自らがアプリの遅さに気がつかなければ、管理者もそれに気がつくことがない。また、
遅いことを認識し、管理者に連絡するというフローが構築出来なければ、管理者も気づきようが無いため、ここまでの解析にたどり着けないことの方が実際の所だと思える。そのため、利用者が自分のアプリが普通よりも遅いという点、あるいは普段よりも遅くなっているという点を何かしらかの方法でロギングし、いつもよりも遅くなっているのか、他の利用者との兼ね合いでファイルシステムやストレージの稼働状況が上がっていることが起因する問題なのか、どうかという点に気づいてもらうための仕組みを構築することが重要である。

4.5.4 まとめまとめとして、考察で述べた点をまとめると、以下の 2 点に集約されると考えている。
1. ファイルシステムを含めた運用関連ミドルウェアの管理者機能に、利用者のアプリケーション実行結果の状況を Strace に類する情報やダイジェスト情報をログ出力できるような機能が必要なのではないか。また、ダイジェスト情報については、利用者に通知するような仕組みが必要なのではないか。
2. 実行時間の調整は必要だが、ファイルシステムやストレージ・システムの常時の健全性の指標として、特定の性能評価プログラムを定期的に走らせて、その結果を利用者に見える形で提示する仕組みを構築することが必要ではないか。そのために、自分のアプリがどの時間に実行されたのかのマッチングがとれる状
態にすることが必要である。

67

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

5 今後に向けての提言
計算機の利用において、演算のチューニングは昔から大きな課題として認識され、実施されている。例えば、ジョブ全体の経過時間を測定し、過去のそれや他のジョブのそれと比較し性能を推測するという簡単な方法か
ら、サブルーチンや DO-loop,for-loop 毎に CPU 時間を集計しホットスポット解析する方法、並列計算におけるプロセス間の通信時間の測定やプロセス間のロードインバランスの検討、更に、CPU のプロファイリングツ
ールを使用して、CPU内の演算リソースの詳細な利用率を測定し分析する方法等、様々なものが存在している。
また、計算機資源の提供者であるシステム管理者にとどまらずユーザも、これらの方法を用い演算のチューニングに関心を持ち日々高速化を目指してプログラムの改良を行っていると思われる。
ところが、同じ計算機の利用において、ファイル I/O のチューニングとなると、その取り組みはまだまだであると言わざるを得ない。どのように I/O の性能を評価すればいいのか手がかりが無い、そもそも I/O をチュ
ーニングするという考え方が浸透していないのが現状であろう。
本 WG はこのような状況の中で活動を開始した。大規模ストレージ WG 等過去の活動の成果を受け、ユーザ視点でファイル I/O のチューニングについて議論してきた。前半は、会員の持つファイルシステムの問題点を出し合い、アプリケーションの I/O 特性を分析すると共に、インターフェース動向、テープ媒体、ストレージモ
ニタリング技術等のストレージ技術動向を調査し、現状を整理した。後半は、ファイルシステム性能評価結果
及びチューニングの指針についてブレーンストーミングを行い、分析ツールの開発や改良等について議論を重ねた。特に、ユーザに I/O 改善の機会を気付いてもらうための方法は、多くの時間を割いて議論を行い、I/O
比率の簡易確認(ステップ 1)、想定 I/O 量、I/O 性能、システム負荷の確認(ステップ 2)、システムコール分
析(ステップ 3)、システム管理者による詳細分析(ステップ 4)に整理した。I/O 改善の手段を明確にすること
で、計算機ユーザによる I/O チューニング活動の活発化を期待するものである。また、この中で、I/O 分析ツールである IO-Dock を開発・改良し、公開できることになったのは WG メンバ全員の歓びである。詳細は、本報告書の第 3 章及び資料 3 をご覧いただきたい。
2012 年 9 月からの約 2 年半の WG 活動を終了するに当たり、今後の課題について WG での議論を踏まえ、いくつか提言する。一つ目は、I/O に関する様々な技術についてである。
(1) ユーザプロセスでの I/O 性能測定、定常的なファイルシステム状況監視機能、mmap や並列プログラミ
ングを用いた際の I/O 情報採取等の測定技術に関すること(2) バッチ実行時の I/O 情報取得、I/O に関するチューニングガイドや事例集等のチューニング支援技術に関すること(3) ユーザプログラムからストレージデバイスまでを関連付けて監視できるツールや、OS 統計情報との連携等のシステム全体での情報採取技術に関することが求められている。詳細は本報告書第 2.4 節をご覧頂きたい。二つ目は、I/O チューニングに対するユーザのモチベーションの上げ方についてである。
「課金すればチューニングせざるを得ない。
」、「ジョブ終了時の出力情報に I/O 性能値を表示させるだけでも効果があるのでは。
」という話も出てきたが、本章の最初に述べたよ
うに、I/O のチューニングの認知度はまだまだ高いとは言えないのが現状であり、今後も議論が必要と思われる。三つ目は、並列 I/O についてである。数値シミュレーションやデータ処理の大規模化に伴い並列度の高いジョブが増えるにつれ、
入出力ファイルの数が増大しており、ファイルシステムの負荷が増大する傾向にある。
MPI-IO の利用や HDF5、
KVS 等のメタデータフォーマットの活用の特質を考える時期に来ていると考えられる。
最後に、SS 研事務局 WG 運営に対して感謝の意を表すると共に、本報告書がファイルシステム利用の高度化への一助となることを願っている。

68サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

付 録

69

成果報告書

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

資料 1 ストレージ技術動向 (2013 年 1 月時点)

1

2

3

4

5

6

70

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

7

8

9

10

11

12

71

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

13

15

72

成果報告書

14

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

資料 2 モニタリング技術紹介 (2013 年 1 月時点)

1

2

3

4

5

6

73

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

7

8

9

10

11

12

74

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

13

14

15

16

17

18

75

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

資料 3 システムコール分析ツール「IO-Dock」使用手引書
1. 機能概要
本ツールはトレースログ(strace、truss)の分析ツールです。
トレースログを分析し、システムコール毎の実行回数、実行時間等を集計することでそのトレースログが対象としているツールの動作を把握しやすくします。

2. 動作環境本ツールを使用する場合、以下の基本ソフトウェアが必要です。
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 5

3. 導入方法
インストールしたいディレクトリに移動し、以下のようにコマンドを実行し本ツールの tar.gz ファイルを展開してください。
tar xfz <tar.gz ファイルを格納したディレクトリ>/IO-Dock-1.0.0.tar.gz

4. 使用方法
本ツールを使用した分析の大まかな流れは以下の通りです。
(1) 中間ファイルを作成する。
(2) システムコール毎に実行回数、実行時間等を集計する。
(3) 着目したシステムコールを掘り下げて分析する。

4.1 分析の流れ
本ツールを使用した分析の流れを説明します。
(1) ツールの準備
本ツールの tar.gz ファイルを展開し、作成されたディレクトリに移動します。
(2) 中間ファイルの作成
strace や truss の出力ファイルから本ツール用の中間ファイルを作成します。
中間ファイルを作成するのに以下のように「make_im_data.pl」スクリプトを実行します。
【実行例】$ ./make_im_data.pl ./strace.log -o ./strace.log.tmp_data(3) システムコール毎の集計
システムコール全体の状況を把握するために以下のように「analyze_summary.pl」スクリプトを実行します。
【実行例】$ ./analyze_summary.pl ./strace.log.tmp_data76サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書(4) 調査システムコールの絞り込み(3)の結果より、詳細に分析するシステムコールを絞り込みます。
【着目例】
・実行回数の多いシステムコール
・処理時間の長いシステムコール
・エラーの多いシステムコール(5) 対象ファイルの確認着目したシステムコールが対象にしているファイルを確認するため、以下のように「analyze_summary.pl」スクリプトを「--func」オプション指定で実行します。
【実行例("write"を確認する場合)】$ ./analyze_summary.pl ./strace.log.tmp_data --func write(6) ファイル IO 処理の確認(5)の結果を元に、操作対象のファイルに対する IO 長別の実行回数、単位時間当たりのスループット、およびファイル offset の推移などを確認し IO の傾向を分析します。
・analyze_io_dist.pl：IO 長別のヒストグラム用のデータを出力します。
・analyze_io_per_time.pl：単位時間当たりの IO 量および IO 回数を出力します。
・analyze_syscall_per_time.pl：単位時間当たりのシステムコールの実行回数を出力します。

この際、各スクリプトで「--csv」オプションを指定した出力をファイルに保存し、そのファイルを入力として「--plot」オプションを使用することでグラフを作成することができます。これにより IO の傾向を視覚的に確認することができ把握しやすくなります。
(7) 出力結果の分析(6)の結果を元に問題点、及び改善点の検討を行います。

5. リファレンス
各スクリプトでは「make_im_data.pl」によって作成された中間データを基に strace(truss)の出力の解析を行い、コマンド毎に対象とする情報を抽出し表示します。
また、各スクリプトは自身の CSV 出力結果のファイルを入力として、そのグラフを作成することができます。
strace(truss)の出力は、それぞれ以下のオプションを指定して実行したものを対象とします。
strace：strace -ttTf -o <log_file> <command>truss ：truss -aefldE -vall -rall -wall -o <log_file> <command>77サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

5.1 make_im_data.pl【概要】
strace(truss)の出力を読み込みデータ解析用の中間ファイルを作成します。
【コマンドライン】
make_im_data.pl <log_file> [-o <tmp_file>]
make_im_data.pl -h【オプション】-h：usage を表示します。
-o <tmp_file>：出力する中間ファイル名を指定します。
【実行例】$./make_im_data.pl ./strace.log -o ./strace.log.tmp_data

5.2 analyze_summary.pl【概要】
strace の結果を読み込み、実行されているシステムコールに関して以下の情報を出力します。
・実行回数
・成功回数
・失敗回数
・実行時間(トータル、平均、最短、最長)・読み込み(書き込み)サイズ(トータル、平均、最少、最大)
各情報については実行されたシステムコール、対象となったファイルで絞り込んで表示が可能です。
【コマンドライン】
analyze_summary.pl -hanalyze_summary.pl <tmp_file> [-t <target_file_name>][--func [<function>] [-e]][-d <exclude_dir>,<exclude_dir>,...][-s <exclude_ext>,<exclude_ext>,...][--csv]
analyze_summary.pl <data_file> --plot <param> --title <title>--outfile <name> [--success] [--error]【オプション】
共通-h：usage を表示します。
分析-t <target_file_name>："target_file_name"に指定されたファイルに対するシステムコールの情報を出力します。
--func [<function>] ：各ファイルに対して"function"に指定されたシステム
コールの情報のみを出力します。
「-e」オプション
78

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

指定時には"function"の指定まで必須です。
-e：システムコールがエラーとなった際のエラー種別を出力します。

-d <exclude_dir>："exclude_dir"で指定されたディレクトリ配下のファイルに対する情報を出力から除外します。
カンマ区切りで複数指定可能です。

-s <exclude_ext>："exclude_ext"で指定されたファイルに対する情報を出力から除外します。カンマ区切りで複数指定可能
です。

--csv

：各フィールドの区切り文字を空白文字から","に変更します。

グラフ化--plot <param> ：分析結果をグラフ化する際に指定します。パラメータにより出力するデータ種別を変更します。
※ 分析時に「-e」オプションなしで出力されたデータを対象とします。
COUNT - システムコール(対象ファイル)毎の成功回数と失敗回数の積み上げグラフ。
TIME - システムコール(対象ファイル)毎のトータル
実行時間の棒グラフ。
IO- 対象ファイル毎のトータル IO 量の棒グラフ。
--title <title> ：グラフのタイトルを指定します。
--outfile <name>：出力するファイル名を指定します。出力ファイル名は本オプションで指定された文字列の末尾に拡張子".png"を付加した名前となります。
--success：出力するデータを指定します。
「--plot」オプションのパラメータとして“COUNT"が指定された場合のみ指定可能です。本オプションが指定された場合、成功回数のみを出力します。
「--error」オプションとは排他です。

--error：出力するデータを指定します。
「--plot」オプションのパラメータとして“COUNT"が指定された場合のみ指定可能です。本オプションが指定された場合、失敗回数のみを出力します。
「--success」オプションとは排他です。

【実行例】
オプションなし$ ./analyze_summary.pl ./strace.log.tmp_data--func 指定$ ./analyze_summary.pl ./strace.log.tmp_data --func write79サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書--func <function> -e 指定$ ./analyze_summary.pl ./strace.log.tmp_data --func ioctl -e

5.3 analyze_io_dist.pl【概要】
各 IO 長の読み込み(書き込み)が何回あったかを出力します。
出力は一定範囲(2 の n 乗+1～2 の n+1 乗)の各合計回数と 1byte ごとの回数の2 パターンが出力されます。
【コマンドライン】
analyze_io_dist.pl -hanalyze_io_dist.pl <tmp_file> [-t <target_file>][-d <exclude_dir>,<exclude_dir>,...][-s <exclude_ext>,<exclude_ext>,...][--csv]
analyze_io_dist.pl <data_file> --plot --title <title> --outfile <name>[--read] [--write]【オプション】
共通-h：usage を表示します。
分析-t <target_file_name>："target_file_name"に指定されたファイルに対するシステムコールの情報を出力します。
-d <exclude_dir>："exclude_dir"で指定されたディレクトリ配下のファイルに対する情報を出力から除外します。カンマ
区切りで複数指定可能です。

-s <exclude_ext>："exclude_ext"で指定されたファイルに対する情報を出力から除外します。カンマ区切りで複数指定可能
です。

--csv

：各フィールドの区切り文字を空白文字から","に変更します。

グラフ化--plot：分析結果をグラフ化する際に指定します。read、write について各 IO 長毎の回数を出力した棒グラフを出力します。

--title <title> ：グラフのタイトルを指定します。
--outfile <name>：出力するファイル名を指定します。出力ファイル名は本オプションで指定された文字列の末尾に拡張子".png"を付加した名前となります。
--read：出力するデータを指定します。本オプションが指定された
場合、read のデータのみを出力します。
「--write」
80サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

オプションとは排他です。
--write：出力するデータを指定します。本オプションが指定された場合、write のデータのみを出力します。
「--read」
オプションとは排他です。

【実行例】
オプションなし$ ./analyze_io_dist.pl ./strace.log.tmp_data

5.4 analyze_syscall_per_time.pl【概要】
単位時間当たりのシステムコールの実行回数を出力します。
【コマンドライン】
analyze_syscall_per_time.pl -hanalyze_syscall_per_time.pl <tmp_file> --func <function>[-i <interval_time>] [-t <target_file>][-d <exclude_dir>,<exclude_dir>,...][-s <exclude_ext>,<exclude_ext>,...] [--csv]
analyze_syscall_per_time.pl <data_file> --plot --title <title>--outfile <name> [--success] [--error]【オプション】
共通-h：usage を表示します。
分析--func <function>-i <interval_time>：対象とするシステムコールを指定します。分析時に必須です。
：データを出力する時間を秒で指定します。デフォルトは
1 秒で小数も指定可能です。

-t <target_file_name>："target_file_name"に指定されたファイルに対するシステムコールの情報を出力します。
-d <exclude_dir>："exclude_dir"で指定されたディレクトリ配下のファイルに対する情報を出力から除外します。カンマ
区切りで複数指定可能です。

-s <exclude_ext>："exclude_ext"で指定されたファイルに対する情報を出力から除外します。カンマ区切りで複数指定可能
です。

--csv

：各フィールドの区切り文字を空白文字から","に変更します。

グラフ化81

サイエンティフィック・システム研究会--plot

ファイルシステム利用技術 WG

成果報告書：分析結果をグラフ化する際に指定します。単位時間毎のトータル実行回数、成功回数、失敗回数いずれかの散布図を出力します。デフォルトはトータル実行回数です。

--title <title> ：グラフのタイトルを指定します。
--outfile <name>：出力するファイル名を指定します。出力ファイル名は本オプションで指定された文字列の末尾に拡張子".png"を付加した名前となります。
--success：出力するデータを指定します。本オプションが指定された
場合、成功回数のみを出力します。
「--error」オプションとは排他です。

--error：出力するデータを指定します。本オプションが指定された場合、失敗回数のみを出力します。
「--success」
オプションとは排他です。

【実行例】$ ./analyze_syscall_per_time.pl ./strace.log.tmp_data --func lstat64

5.5 analyze_io_per_time.pl【概要】
単位時間当たりの IO 量、および IO 回数を出力します。また、IO システムコール
1 回毎の IO サイズ、オフセット位置等の出力も可能です。
【コマンドライン】
analyze_io_per_time.pl -hanalyze_io_per_time.pl <tmp_file> [-i <interval_time>][-t <target_file> [--offset <function>]][-v <exclude_dir>,<exclude_dir>,...][-s <exclude_ext>,<exclude_ext>,...] [--csv]
analyze_io_per_time.pl <data_file> --plot <param> --title <title>--outfile <name> [--read] [--write]【オプション】
共通-h：usage を表示する。
分析-i <interval_time>：データを出力する時間を秒で指定します。小数も指定可能です。デフォルトは 1 秒です。

-t <target_file_name>："target_file_name"に指定されたファイルに対するシステムコールの情報を出力します。
--offset <function> ：対象とする IO システムコールを指定します。
本オプションが指定された場合には単位時間当たりのトータルではなく、そのシステムコール 1 回毎の82

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

開始時間、実行時間、IO サイズ、オフセット位置を出力します。
-d <exclude_dir>："exclude_dir"で指定されたディレクトリ配下のファイルに対する情報を出力から除外します。カンマ
区切りで複数指定可能です。

-s <exclude_ext>："exclude_ext"で指定されたファイルに対する情報を出力から除外します。カンマ区切りで複数指定可能
です。

--csv

：各フィールドの区切り文字を空白文字から","に変更します。

グラフ化--plot <param> ：分析結果をグラフ化する際に指定します。パラメータにより出力するデータ種別を変更する。
※ COUNT、IO は「--offset」オプションなしのデータ、
TIME、SIZE、OFFSET は「--offset」オプション付きのデータを対象とします。
COUNT - 単位時間当たりの read、write の実行回数の散布図を出力します。
IO- 単位時間当たりの read、write の IO 量の散布図を出力します。
TIME - システムコールの実行時間の散布図を出力します。
SIZE - システムコール毎の IO サイズの散布図を出力します。
OFFSET - システムコール毎のオフセット位置の散布図を出力します。
--title <title> ：グラフのタイトルを指定します。
--outfile <name>：出力するファイル名を指定します。出力ファイル名は本オプションで指定された文字列の末尾に拡張子".png"を付加した名前となります。
--read：出力するデータを指定します。本オプションが指定された
場合、read のデータのみを出力します。
「--plot」
オプションのパラメータとして"COUNT"、または"IO"が指定された際に指定可能です。
「--write」オプションとは排他です。

--write：出力するデータを指定します。本オプションが指定された場合、write のデータのみを出力します。
「--plot」
オプションのパラメータとして"COUBT"、または"IO"が指定された際に指定可能です。
「--read」オプションとは
排他です。

【出力例】
83

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

オプションなし$ ./analyze_io_per_time.pl ./strace.log.tmp_data-t target_file --offset <func>指定$ ./analyze_io_per_time.pl ./strace.log.tmp_data -t file --offset write

6. 変更履歴
V1.0.0(2015/01/21)
・初版作成。

84サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

参考文献

85

成果報告書

サイエンティフィック・システム研究会

ファイルシステム利用技術 WG

成果報告書

参考文献




サイエンティフィック・システム研究会 大規模ストレージ WG：「大規模ストレージ WG 成果報告書～
大規模ストレージの課題と今後の対応」、2011 年 5 月
Bertin, E. et al. 2002, ADASS XI, ASP conf. Ser. 281, 228
Joye, W.A., Mandel, E. 2003, ADASS XII, ASP conf. Ser. 295, 489

86

【発行者】サイエンティフィック・システム研究会【編 集】サイエンティフィック・システム研究会 ファイルシステム利用技術ＷＧ【発行日】2015 年 5 月 22 日
◆ ◆ ◆
＜連絡先＞
サイエンティフィック・システム研究会 事務局〒105-7123 東京都港区東新橋 1-5-2 汐留シティセンター
TEL : 03-6252-2582、FAX : 03-6252-2798
E-mail : office@ssken.gr.jp
URL : http://www.ssken.gr.jp/MAINSITE/※著作権は各原稿の著者または所属機関に帰属します。無断転載を禁じます。