ファイル I/O の分析と改善 - サイエンティフィックシステム研究会

ファイルシステム利用技術 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 活動実績 ·················································································· 2
2 ファイルシステムの利用における現状と課題 ·················································· 4
2.1 ファイルシステムの利用動向 ································································ 4
2.1.1 ローカルファイルシステム ······························································ 4
2.1.2 ネットワークファイルシステム ·························································· 5
2.1.3 並列分散ファイルシステム ······························································ 5
2.2 I/O 効率の改善に向けた方策について ························································ 6
2.3 I/O 効率の改善方法（ユーザに改善の機会を気付いてもらうための方法）························· 6
2.3.1 ステップ 1：I/O 比率の簡易確認 ························································· 8
2.3.2 ステップ 2：想定 I/O 量,想定 I/O 性能,システム負荷の確認································ 12
2.3.2.1 想定 I/O 量の確認 ································································· 12
2.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 まとめ ··············································································· 41
i
サイエンティフィック・システム研究会
ファイルシステム利用技術 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 ID
JOB NAME
JOB TYPE
: 30005
: SS_IOR
: BATCH
省略
JOB START DATE
JOB 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)
:3
USER 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 ID
JOB NAME
JOB TYPE
: 30008
: SS_HPL
: BATCH
省略
JOB START DATE
JOB 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 2015
rchar: 221931
wchar: 31074297546
省略
Every 1.0s: /bin/cat /proc/19084/io
Tue Jan 20 07:31:35 2015
rchar: 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_BLK
WRITE $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 2015
rchar: 221935
wchar: 20119037651
省略
Every 1.0s: /bin/cat /proc/7068/io
Tue Jan 20 09:11:00 2015
rchar: 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] 0
33198293 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_IOR
JOB 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 USER
DISK READ DISK WRITE SWAPIN
IO>
COMMAND
省略
TID
1730
23245
23246
PRIO USER
be/4 root
be/4 abebe
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
SWAPIN
IO>
COMMAND
0.00 % 94.23 % [flush-8:0]
0.00 % 94.15 % ./IOR~TEST/test
0.00 % 93.55 % ./IOR~TEST/test
省略
Total
TID
23246
23245
DISK READ: 159.06 M/s | Total DISK WRITE: 3.18 K/s
PRIO USER
DISK READ DISK WRITE SWAPIN
IO>
COMMAND
be/4 abebe
86.76 M/s
0.00 B/s 0.00 % 99.73 % ./IOR -w~TEST/test
be/4 abebe
72.29 M/s
0.00 B/s 0.00 % 97.59 % ./IOR -w~TEST/test
省略
Total
TID
23245
23246
DISK READ: 0.00
PRIO USER
be/4 abebe
be/4 abebe
B/s | Total DISK WRITE: 158.91 M/s
DISK READ DISK WRITE SWAPIN
IO>
COMMAND
0.00 B/s 88.15 M/s 0.00 % 94.18 % ./IOR -w~TEST/test
0.00 B/s 70.79 M/s 0.00 % 94.17 % ./IOR -w~TEST/test
省略
Total
TID
23245
23246
DISK READ: 135.87 M/s | Total DISK WRITE: 16.67 K/s
PRIO USER
DISK READ DISK WRITE SWAPIN
IO>
COMMAND
be/4 abebe
67.14 M/s
0.00 B/s 0.00 % 99.99 % ./IOR -w~TEST/test
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 USER
DISK 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
TID
19084
19083
DISK READ: 11.84 K/s | Total DISK WRITE: 6.65 K/s
PRIO USER
DISK READ DISK WRITE SWAPIN
IO>
COMMAND
be/4 abebe
54.04 M/s
0.00 B/s 0.00 % 96.27 % ./IOR -w~TEST/test
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 USER
DISK READ DISK WRITE SWAPIN
IO>
COMMAND
省略
TID
636
7067
7068
PRIO USER
be/3 root
be/4 abebe
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
SWAPIN
IO>
COMMAND
0.00 % 0.31 % [jbd2/sda3-8]
0.00 % 0.00 % ./IOR -w~RGE_TEST
0.00 % 0.00 % ./IOR -w~RGE_TEST
DISK READ: 0.00
PRIO USER
be/4 abebe
be/4 abebe
B/s | Total DISK WRITE: 1631.40 B/s
DISK READ DISK WRITE SWAPIN
IO>
COMMAND
0.00 B/s
0.00 B/s 0.00 % 19.49 % ./IOR -w~RGE_TEST
0.00 B/s
0.00 B/s 0.00 % 1.94 % ./IOR -w~RGE_TEST
省略
Total
TID
7067
7068
省略
※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/date
2015 年 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 DATE
JOB 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
FC-SAN
Switch
RAID
×90
図 4.1.1 JSS の全体構成
FC-SAN
Switch
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
Compute
node
Compute
Filenode
node
Cache
Compute
Compute
node
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
unlink
fstat
stat
statvfs
read
write
実⾏回数 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
unlink
fstat
stat
statvfs
read
write
IO速度
3.0 MB
3.0 GB/s
0.8 MB 24.4 GB/s
ノード 1 の結果
syscall
open
close
unlink
fstat
stat
statvfs
read
write
実⾏回数 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
unlink
fstat
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 ms
176
1.4 ms
365
0.0 ms
0.0 ms
56.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 ms
332
61.0 ms
34
1.4 ms 1,460
0.2 ms
20
2.0 ms
2
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 ms
538
0.5 ms 1,022
0.1 ms 5,110
0.0 ms
0.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 ms
465
59.8 ms
9
1.1 ms
465
0.0 ms
0.0 ms
64.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 ms
125 B
0.0 ms
12 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/s
write
stat (Top5)
ファイル
ファイル
RESULT/shock5_jet1-3-reordered_0001.rslt
時間
51.5 ms
0.1 ms
0.4 ms
0.1 ms
0.0 ms
52.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
openat
close
unlink
fstat
fstat64
stat
stat64
lstat
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,202
0
0 ms
24,704
0
9.7 sec
2.5
1,005
0
0.9 sec
1.2
IO量
14 GB
404 MB
平均IO⻑
584 KB
402 KB
IO速度
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.1231
137
1,006
59
0.0426
62
1,018
58
0.0421
60
1,012
1,224
0.0067
47
37
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.1288
74
1,014
0.1579
70
1,019
0.1467
67
931
0.1355
62
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/djvuchar
42
サイエンティフィック・システム研究会
ファイルシステム利用技術 WG
成果報告書
表 4.2.1 2013 年 7 月 4 日 IO-Dock 分析結果(メタ I/O 系システムコール)
システムコール
実行回数 error 回数
処理時間
I/O 量
メタデータ
ファイル I/O
open(open64)
close
unlink
mkdir
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,288
2
4
0
0
0
7
637,377
0
38,273
32.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)
システムコール
ファイル
kanseki.cat
read
(TOP5)
write
(TOP5+α)
実行回数
処理時間
データ量
I/O 速度
550,729
39.1 sec
1.35 GB
34.5 MB/s
tagint.XX
46,132
12.9 sec
377.9 MB
29.2 MB/s
kanseki.ip
45,699
11.3 sec
374.3 MB
33.1 MB/s
kanseki.i1
6
4.9 sec
187.1 MB
38.1 MB/s
1
104
19
23,066
22,849
22,849
22,849
182,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 MB
451.1 MB
48 KB
188.9 MB
187.1 MB
187.1 MB
187.1 MB
187.1 MB
38.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
kanseki.t1
kanseki.cat
tmpalldat
tagint.XX
kanseki.idx
kanseki.t1
kanseki.i1
kanseki.ip
表 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,169
123
43
318,275
318,272
182
0
318,025
432
0
0
0
318,272
0
16
サイエンティフィック・システム研究会
ファイルシステム利用技術 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,348
259
3.7 sec
-
close
200,984
2
6.8 msec
-
unlink
17
4
720 msec
-
mkdir
1
0
0.2 msec
-
rmdir
1
0
0.0 msec
-
fstat64
398,727
0
2.6 msec
-
lstat64
872,535
5
22.7 sec
-
2,851
1,589
85.5 msec
-
stat(stat64)
ファイル I/O
read
1,065,063
0
79.7 sec
2.7GB
write
2,968,714
39,219
51.6 sec
1.7GB
44
サイエンティフィック・システム研究会
ファイルシステム利用技術 WG
成果報告書
表 4.2.5 2014 年 4 月 15 日 IO-Dock 分析結果(ファイル I/O)
システムコール
ファイル
実行回数
処理時間
データ量
kanseki.cat
read
(TOP5)
566,588
36.1 sec
1.39 GB
38.4 MB/s
tagint.XX
47,236
12.3 sec
386.9 MB
31.2 MB/s
kanseki.ip
47,069
10.7 sec
385.5 MB
35.7 MB/s
kanseki.i1
6
5.1 sec
192.7 MB
37.3 MB/s
kanseki.t1
1
4.4 sec
192.7 MB
43.2 MB/s
105
21.6 sec
462.4 MB
21.4 MB/s
tmpalldat
2,629,037
13.5 sec
224.8 MB
16.5 MB/s
tagint.XX
23,618
4.5 sec
193.4 MB
42.3 MB/s
kanseki.idx
23,534
4.5 sec
192.7 MB
42.5 MB/s
kanseki.t1
23,534
4.0 sec
192.7 MB
47.8 MB/s
kanseki.i1
23,534
3.9 sec
192.7 MB
49.1 MB/s
kanseki.ip
188,267
0.6 sec
192.7 MB
296.5 MB/s
kanseki.cat
write
(TOP5+α)
I/O 速度
表 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,090
265
3.17 sec
-
close
198,740
2
2.2 msec
-
unlink
19
4
0.73 sec
-
mkdir
1
0
0.1 msec
-
rmdir
ファイル I/O
1
0
0.2 msec
-
stat(fstat64, etc)
1,273,052
1,624
18.66 sec
-
read
1,065,598
0
89.34 sec
2.7GB
write
546,661
39,393
63.73 sec
1.7GB
表 4.2.8 2014 年 9 月 5 日 IO-Dock 分析結果(ファイル I/O)
システムコール
ファイル
実行回数
処理時間
データ量
kanseki.cat
read
(TOP5)
570,208
42.64 sec
1.40 GB
32.86 MB/s
tagint.XX
47,460
13.19 sec
388.79 MB
29.48 MB/s
kanseki.ip
47,411
11.48 sec
388.37 MB
33.83 MB/s
kanseki.i1
6
6.51 sec
194.18 MB
29.83 MB/s
kanseki.t1
1
5.20 sec
194.18 MB
37.34 MB/s
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,730
4.03 sec
194.39 MB
48.24 MB/s
kanseki.idx
23,705
3.70 sec
194.18 MB
52.48 MB/s
kanseki.t1
23,705
3.99 sec
194.18 MB
48.67 MB/s
kanseki.i1
23,705
3.56 sec
194.18 MB
54.54 MB/s
kanseki.ip
189,633
3.91 sec
194.18 MB
49.66 MB/s
kanseki.cat
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
ＮＦＳ(NFSv3)マウント
ファイル(NFS)
サーバ x4
ＮＡＳ(home)x2
図 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量
0
0.9 ms 145 MB
0
0.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
0
0.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.000034
open
12
0
0.000347
0.000029
0.000010
0.000214
getdents
12
0
0.000650
0.000054
0.000027
0.000065
close
19
0
0.000187
0.000010
0.000008
0.000019
fstat
13
0
0.000112
0.000009
0.000008
0.000011
statfs
1
0
0.000011
0.000011
0.000011
0.000011
lseek
1
0
0.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
0
0.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
0
0.038194
0.003183
0.000009
0.038064
getdents
12
0
0.320007
0.026667
0.000048
0.163230
close
18
0
0.000177
0.000010
0.000008
0.000016
fstat
13
0
0.000144
0.000011
0.000008
0.000042
statfs
1
0
0.000011
0.000011
0.000011
0.000011
lseek
1
0
0.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
0
1.657865
0.010765
0.000008
0.304729
151
0
0.001917
0.000013
0.000008
0.000065
3369
0
0.090412
0.000027
0.000008
0.003487
4782
0
0.182544
0.000038
0.000015
0.002006
276
0
0.002795
0.00001
0.000007
0.000063
172
0
0.002198
0.000013
0.000009
0.000065
44
14
0.000527
0.000012
0.000008
0.000029
156
0
0.005997
0.000038
0.000011
0.000388
表 4.3.6 SWarp 実行時の I/O システムコールの多いファイル(open)
ファイル名
実行回数 エラー回数 処理時間[s]
mfl_*_resamp.fits
46
0
0.024778
mfl_*_resamp.weight.fits
46
0
0.009031
共有ファイル等
45
34
0.000506
coadd.fits
1
0
0.000192
coadd.head
1
1
0.000108
coadd.weight.fits
1
0
0.000148
mfl_b.lis
1
0
0.000368
swarp.conf
1
0
0.000278
swarp.xml
1
0
0.002003
mfl_*.fits
46
0
0.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
0
0.520030
共有ファイル等
11
0
0.000123
coadd.fits
1
0
0.304272
coadd.weight.fits
1
0
0.304729
mfl_b.lis
1
0
0.000010
swarp.conf
1
0
0.000011
swarp.xml
1
0
0.001311
mfl_*.fits
46
0
0.000683
表 4.3.8 SWarp 実行時の I/O システムコールの多いファイル(read)
ファイル名
実行回数
処理時間[s] 処理量[byte]
mfl_*.resamp.fits
1462
0.032339
46,903,680
mfl_*.resamp.weight.fits
1462
0.033042
46,903,680
mfl_*fits
431
0.024897 103,003,456
mf._b.lis
2
0.000020
308
swarp.conf
2
0.000023
5,031
共有ファイル等
10
0.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
標準エラー
7
0.010741
301
coadd.fits
925
0.026552
30,291,840
coadd.weight.fits
925
0.026356
30,291,840
swarp.xml
1
0.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]
1
0
0.304272
0.304272
0.304272
0.304272
1
0
0.000010
0.000010
0.000010
0.000010
925
0
0.026552
0.000029
0.000020
0.000078
1
0
0.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
0
0.008003
0.000008
0.000006
0.000034
335
0
0.003771
0.000011
0.000008
0.000094
246
145
0.007349
0.00003
0.000007
0.000186
435
0
0.00807
0.000019
0.000014
0.000087
107
0
0.001063
0.00001
0.000006
0.00011
86
0
0.000812
0.000009
0.000006
0.000075
2
1
0.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.00002
0.000015
0.000118
1.958181
0.018301
0.000007
1.93977
0.001254
0.000015
0.000007
0.000241
0.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/ノード
3
2CPU
表 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５)
ファイル
実⾏回数
write
(全9ファイル中Top５)
rfm_run071482.000010.root
/tmp/tmpfpNdvMS
/tmp/tmpfuUpPTV
/tmp/tmpf9tSf1Y
/tmp/tmpfuhiHkD
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
7
3
6
2
401
1
1
1
1
処理時間 データ量
IO速度
35.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/s
329 ms
15 us
13 us
14 us
21 us
312 MB 947 MB/s
1.2 KB
77 MB/s
1.0 KB
77 MB/s
82 B 5.9 MB/s
44 B 2.1 MB/s
表 4.4.4 システムコール分析結果（ディスク I/O 処理関連）
システムコール
メタアクセス open
close
unlink
stat
ファイル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 3 22 ~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 71 43 72 190 2 18 54 45 17 10 9 33 100
10,000
1,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,103
0
48.0sec
26.0GB 1,583,929
0
25.7sec
13.0GB
write
lseek
353
4,750,841
0
3
399.2ms
46.1sec
317.9MB
353
- 3,167,360
0
3
386.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
100000
1000
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
set
set
set
set
set
set
$dir=/tmp
$nfiles=10000
$meandirwidth=20
$meanfilesize=128k
$nthreads=10
$iosize=1m
$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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
ファイル作成(&Open)
ファイル書き込み
ファイル Close
ファイル Open
ファイル追記
ファイル Close
ファイル Open
ファイル読み込み
ファイル Close
ファイル削除
ファイル 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
73
6
サイエンティフィック・システム研究会
ファイルシステム利用技術 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_data
76
サイエンティフィック・システム研究会
ファイルシステム利用技術 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 -h
analyze_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 write
79
サイエンティフィック・システム研究会
ファイルシステム利用技術 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 -h
analyze_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 -h
analyze_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 -h
analyze_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 : [email protected]
URL : http://www.ssken.gr.jp/MAINSITE/
※著作権は各原稿の著者または所属機関に帰属します。無断転載を禁じます。