z/OSでのディスクI/Oパフォーマンスの解析では、解析に必要な情報が不足していたり、I/Oレスポンスやスループットの値を適切に評価できないなどの課題がある。本稿はこれらの課題を踏まえ、解析の精度をより高めるための手法を提案する。
重要なのは、対象I/O処理の「アプリケーション属性」の把握と、その属性に基づいた評価の2点である。これからI/Oパフォーマンス分析を学ぼうとしている技術者に向けて、基本的な考え方や指針を提示したい。
I/Oパフォーマンス解析が困難である理由
アプリケーションのパフォーマンス問題が発生したとき、ミドルウェアなどでの監視結果から、ディスク装置でのI/O遅延が疑われるケースがある。z/OSの場合、パフォーマンス解析は一般に、RMF （Resource Monitoring Facility） という機能で作成したレポートを用いるが、I/O遅延についても同様である。しかし、I/Oパフォーマンスを適切に解析するのは意外に難しい。
I/O遅延の解析では、まずボトルネックとなりうる要素が多く、何が問題かを突き止めるのが難しいという問題点がある。たとえば筆者の経験でも、アプリケーションのレスポンスがときおり悪化する現象が起きたので調査したところ、最終的にはディスク（IBM System Storage DS8000、以下DS8000）のあるランクにI/Oが集中しているとわかったが、この結論に至るまで長期間を要したことがある。
また別のケースでは、アプリケーションのレスポンスが悪化したため、RMFを確認したものの、RMFレポート上では顕著な悪化が見られず、明確な結論に至らなかったこともある。
このような困難を招く原因には、関連するコンポーネントが多く、解析に必要なレポートを十分把握できていないこと、とくに深く解析するためのレポートをうまく利用できていないことがある。
たとえば、RMFレポートの1つである「Cache Subsystem Activity」レポートが取得されていても、現場ではキャッシュ・ヒット率の把握にしか使用されないことが多い。またESSレポートは、DS8000の処理状況を確認するのに重要だが、取得されていないケースもある。
さらにI/Oパフォーマンス解析を困難にしているもう1つの原因として、監視の結果得られたレスポンスやスループットの値を評価する指標が一定値でない点が挙げられる。順次I/OかランダムI/O、キャッシュ・ヒット率、その他のさまざまな要因によって、この指標は変わってくるからだ。ここではこの要因を「アプリケーション属性」と呼び、その把握の重要性を後述する。
現実の業務処理環境では、このアプリケーション属性もさまざまな業務の実行により時々刻々と変化する。加えて技術進歩により、同じアプリケーション属性のI/O処理においてすら、指標値は変わってくる。
z/OS環境のディスクI/Oパフォーマンスに関する資料には、White PaperのようなDS8000開発チームが計測したパフォーマンス･レポート、RMFレポートの1つであるRMF Direct Access Device Activity レポートを中心に解説したIBM社内技術資料、DS8000のパフォーマンスを左右する構成や機能を紹介したRedbookなどがある。しかし前述の課題にどのように対処すべきかを、パフォーマンス評価までの流れを含めて解説した資料は、筆者が把握する限りでは存在しない。
そこで本稿は、このようなI/Oパフォーマンス解析における評価の難しさという課題に対処し、解析の精度をより高める手法を紹介する。まず、提案する解析手法を説明し、さらにこのような解析手法が必要となる理由を説明したうえで、検証結果を提示することで、この手法の有用性を示すことにしよう。
解決策となるパフォーマンス解析手法
I/Oパフォーマンス解析の課題に向けた対応方法として、図表1の手順を紹介する。
まず手順1は、一般的によく行われるRMF Direct Access Device Activity レポートによる調査である。このレポートは、主にz/OSから見たボリューム単位のI/Oレスポンス時間の内訳を表示する。レスポンス時間のうち、z/OS内での待ち（IOSQ）、データ転送時間 （Connect Time）、ディスク装置単独での処理時間（Disconnect Time）、ディスク装置以外での遅延時間 （Pending Time） などがわかる。
IOSQが大きい場合は、z/OS内でのUCB競合が原因と言えるが、そのほかの時間が割合として大きい場合は（ある程度はその原因を推察できるものの）、このレポートだけでは高い精度で原因を特定することはできない。
手順2は、ディスク装置側のボトルネックを見つける、あるいは高い精度で特定するため、他のRMFレポートを利用する際の指針である。ここで、追加のI/O関連RMFレポートの確認により、手順1の解析では不明、もしくは推察にとどまっていたパフォーマンス上のボトルネックを特定できる可能性が高くなる。
まず手順2-1のとおり、Cache Sub system Activity レポートを確認する。このレポートは、ディスク上のキャッシュ･ヒット率やRead／Write比、順次／ランダムのI/O状況など、パフォーマンスを左右するI/O処理の要素 （前述の「アプリケーション属性」） を確認できる。
なぜこのアプリケーション属性の把握がパフォーマンス解析で重要かというと、この属性によって、ディスク装置が処理可能な最大値やI/O処理の応答時間が大きく異なるからである（具体例は後述する）。このレポートで得られた情報は、手順3で指標値と比較する際に利用する。
次に手順2-2 のようにESS レポートを調査し、ディスク装置（本稿ではDS8000を想定）のランクやI/Oポート単位でのI/Oレスポンスやスループットを確認する。現在のディスク装置では、z/OSから見たボリューム単位だけでなく、ランク単位でパフォーマンスを確認することが重要なので、このレポートは必要である。
さらに手順2-3で、ほかにI/O処理のボトルネックとなりうる兆候がないかを知るために、CPU Activity レポートでのI/O interruptionの処理状況、I/O Queuing Activity レポート、Channel Path Activityレポートを再確認する。通常、I/O処理以外のボトルネックについては、I/O評価に入る前段階で調査されていると想定しているので、ここではI/O処理の観点からの再確認となる。
最後に手順3で、ESS レポートなどで得られたレスポンス／スループットをWhite Paperなどで公開されている指標値と比較し、妥当なパフォーマンスが得られているかどうかを評価する。このとき、Cache Subsystem Activity レポートで得たアプリケーション属性を考慮して評価することで、従来の課題である評価の難しさを補い、より精度の高い評価を実現する。
I/Oパフォーマンス解析のポイント
前述した解析手法が重要である理由を、以下に3つの観点から説明する。1つ目は解析に複数のRMFレポートが必要となる理由、2つ目はCache Subsystem Activity レポートでアプリケーション属性を得ることの重要性、3つ目はESSレポートでDS8000のランク単位のパフォーマンスを確認することの重要性である。
◆ 複数のRMFレポートが必要となる理由
本稿で提案する解析手法では、複数種類のRMFレポートが必要になるが、これはI/O処理の流れには複数のコンポーネントが関与するため、ボトルネックとなりうる要素が多数存在するからである。
1種類のRMFレポートがカバーする範囲は限られるので、I/O処理の流れ全体をカバーするにはどうしても複数のレポートが必要になる。たとえば、I/Oパフォーマンス解析の入り口としてよく利用されるDirect Access Device Activity レポートは、あくまでz/OS側の情報であり、ディスク内の情報は得られない。
図表2に、I/O処理の主要なコンポーネントとボトルネックとなりうる要素を示す。
ここではz SystemsサーバーからFICONダイレクターにかけての構成で、以下の要素がボトルネックになりうる。
・ z SystemsのFICONチャネル数、転送幅
・ FICONダイレクターでの集約度、転送幅
またDS8000構成では、以下の要素がボトルネックになりうる。
・ ホスト・アダプタ数、転送幅
・ キャッシュ・サイズ
・ キャッシュ・ヒット率を決める要素
・ 内部プロセッサ（コントローラ）性能
・ デバイス・アダプタ数
・ 物理ディスク数や物理ディスクの性能
・ DS8000ではRAIDランク数
・ RAIDタイプ（RAID5／6／10）
このように、I/O処理は複数のコンポーネントにまたがって実行され、ボトルネックとなりうる要素も多岐にわたる。このため、これらをカバーするには複数のRMFレポートが必要となる。確認すべきRMFレポートは、図表3のとおりである。
z SystemsサーバーからFICONダイレクターにかけての処理状況をカバーするRMFレポートは、CPU Activity、I/O Queuing Activity、Channel Path Activity、Direct Access Device Activityの4つのレポートである。DS8000側の処理状況をカバーするのは、Cache Subsystem ActivityとESSの2つである。
これらのレポートをすべて取得して確認することで、ボトルネックとなりうる要素をある程度網羅でき、解析の情報不足が理由でボトルネックが見つからないような結果になる確率を低くできる。
これらのレポートを新たに取得する場合、SMFレコードが増大するため、SMFデータセットのサイズなどについては事前確認が必要である。なお、統計データは一定インターバルでまとめてz/OSが取得するので、I/Oパフォーマンスへの影響を考慮する必要はない。
これらのレポートを取得する際は、RMFのインターバルにも注意が必要である。たとえばインターバルが30分の場合、レポートされる値は30分間の平均値となるため、特定数分のピーク時のボトルネックは特定しにくい。精度の高い解析には、インターバルをできるだけ短くするよう推奨される。筆者は5分インターバル程度を指定し、特定のパフォーマンス解析実施時は、最低値の1分の指定が可能な運用体制が望ましいと考える。
◆ Cache Subsystem Activityレポートの重要性
前項で、Cache Subsystem Activityレポートでの「アプリケーション属性」の把握の重要性に若干触れたが、ここではその具体例を提示する。
I/Oパフォーマンスを左右するアプリケーション属性の代表的な要素には、以下がある。
● I/Oパターン
順次／ランダム処理の割合
データ転送サイズ
Read／Write比
キャッシュ・ヒット率
Writeデータのデステージ率
物理ディスクのシーク率
● 並行度
同時にI/O処理を実施する度合い
なお、この｢アプリケーション属性｣という用語は、I/Oパフォーマンス解析の一般用語ではなく、筆者が名づけたものである。ただしこの用語を使わなくても、I/Oパフォーマンスに詳しい多くの技術者は、その重要性を理解し、それに即した分析を行っている。
｢アプリケーション属性｣を把握する重要性を理解するために、一例として、順次／ランダム処理の違いという観点で考えてみよう。
開発部門が提供するDS8000のパフォーマンス･レポートでは、4KBデータのランダムREADにおける 1ランク（RAID 5 146GB物理ドライブ）の能力は、2200 IOPS（秒当たりのI/O数）が最大IOPSとして計測されている。順次処理と比較するために、秒当たりのデータ転送量を求めると、約8 MB/sec （＝4KB×2200 IOPS）となる。
一方、順次READでの1ランク当たりの最大スループットについては、ランダム処理と同じRAID 5 146GB物理ドライブの能力として、約600MB/secが最大値として計測されている。
このことから、ランダム処理か順次処理かという「アプリケーション属性」の違いによって、1ランクの最大処理能力は8MB/secにも、600MB/secにもなりうることがわかる。たとえば、ランク当たりで300MB/sec転送していた場合、ランクネックか否かはそれだけの情報では判断できない。
前述のすべてのアプリケーション属性は、同様にディスク装置の最大能力を大きく左右する。それゆえ、I/Oパフォーマンスの分析には、対象処理のアプリケーション属性をできるだけ正確に把握することが重要となる。把握するうえで大きな助けとなるのが、Cache Subsystem Activityレポートである。
◆ ESS レポートの重要性
ボリューム単位のI/Oレスポンスやスループットは、Direct Access Device Activity レポートから得られるが、ランクやI/Oポート単位の値はESS レポートが必要である。なぜランク単位の値が重要かを理解するには、DS8000のRAIDランク（図表4で RAID 5と示されている部分）と、z/OSから見えるボリュームの関係を理解する必要がある。
図表4が示すように、DS8000内の物理ディスクは、ランクというRAIDを構成するグループに分かれている。z/OSはボリュームという単位に対してI/O要求を行うが、実際には、ボリュームは物理的にRAIDランクに含まれる複数の物理ディスク・ドライブに分散して配置されている。同じランクに含まれるボリューム群のI/Oパフォーマンスは相互に影響し合うため、このランク単位での処理状況の把握が重要である。
このように、I/Oパフォーマンスを評価する前提としてランク単位のパフォーマンスを把握するので、ESSレポートの取得が重要となる。
ケーススタディ：実機検証結果
提案する解析手法の有効性を確認するため、検証環境で擬似的なI/Oパフォーマンス遅延を再現し、解析手法を検証した。実際の業務処理のようにランダム／順次、 Read／Writeが混在するI/Oを再現すべく、DB2 for z/OSの表に対してランダムに更新するアプリケーションを開発した。
◆ 検証環境・前提
以下の環境および前提で検証を実施した。
・ z/OS V2R1 （RMFインターバルは1分）
・ DS8870 （64GBメモリ、146GBドライブ、RAID 5×1ランク）
・ DB2 for z/OS V9
・ ランダムUPDATEを行うDB2バッチ･ジョブを16並列で実行
◆ 擬似的なI/Oパフォーマンス遅延の再現
ジョブのパフォーマンスをDB2の会計レポートで確認すると、図表5のようになった。
Class 2 DB2内処理時間は2分41秒であるが、Class 3 DB2内待ち時間のSYNCHRON I/Oが1分19秒を占めている。つまり処理時間の約50％が、同期I/Oによる待ち時間であった。このためアプリケーション処理時間を短縮する方法の1つとして、I/O処理時間の短縮が考えられる。
◆ RMFレポートの調査
I/Oパフォーマンスを解析するため、まずDirect Access Device Activity、Cache Subsystem Activity、ESSの各RMFレポートを調査した。得られた主な結果は、以下のとおりである。
（1）Direct Access Device Activity レポート
バッチジョブがアクセスしたボリュームの平均I/O応答時間は、図表6のとおり、約1.5msだった。
Response Timeの内訳（Connect Time、Disconnect time、Pending Time、IOSQ Time）からさまざまな可能性が考えられるものの、I/O応答時間の短縮が可能かどうかは、他のレポートの分析が必要となる。
（2）Cache Subsystem Activity レポート
図表7のとおり、単位時間当たりの順次Readが36万2907回 （全体の57％）、順次Writeが27万3259回 （全体の43％）で、ランダム （Normal）のRead／Writeも数は少ないがカウントされていた。またH/Rの値から、キャッシュ・ヒット率は100％近かった。
（3）ESS Rank Statisticsレポート
図表8のとおり、ESS Reportが示す転送量は、Readが203.8MB/sec、Writeが238.3MB/secであった。
◆ パフォーマンスの評価
Cache Subsystem Activityレポートで順次処理が大半であることから、ランク当たりのデータ転送量により評価を試みる。White Paperのパフォーマンス・レポートによると、同等のモデルの最大スループットは、順次Readのみで約600MB/sec、順次Writeのみの場合も約600MB/secである。
検証ケースのReadとWriteを合計すると、約440MB/secとなる。この値は、600MB/secよりも小さいが、以下の理由からRAIDランク能力の限界に抵触していた可能性があると推測する。つまりWhite Paperの最大値はある程度幅をもって考える必要があること、順次ReadとWrite処理が混在していること、わずかではあるがランダム処理が混在していること、などの理由である。
順次処理では、大きな転送サイズで先読みや書き出しを行うが、Read／Writeの混在とランダム処理の混在はデータ一括処理の中断を招き、スループットを低下させる要因となりうる。また、図表8のESSランク・レポートのWrite処理の応答時間（RTIME/OP）が141.4msであることも、ランク能力の限界により、書き出し処理時間が長くなっていることを推察させる。
◆ パフォーマンス改善策の適用
ランクへの負荷を軽減するため、データの半分を別のランクに移動し、再度16並列でジョブを実行した。その結果、以下のような改善が見られた。
・ DB2の会計レポートを確認すると、処理時間が2分41秒から2分25秒に短縮し、同期I/Oによる待ちも約50％から約30％に減少した。
・ Direct Access Device Activityレポート上、ボリュームの平均レスポンスが1.5msから0.6msに減少した。
・ ランク処理は、順次Readが203.8MB/secから268.5MB/secに、 順次Writeは238.3MB/secから306.6MB/secに増加した。
このようにパフォーマンスが向上したことから、解析の結果推測したI/O遅延の原因が妥当だったことが証明できた。
本稿では、z/OSでのI/Oパフォーマンス解析で起こりがちな評価の難しさという課題に対して、解析の精度をより高める手法を紹介した。さまざまな要素の影響を受けるI/Oパフォーマンスの解析は容易ではないが、複数種類のRMFレポートから得られたレスポンスやスループットについて、アプリケーション属性を考慮しながら適切に評価することで、より精度の高い解析が可能になる。
検証例は比較的単純なものであるが、アプリケーション属性をできるだけ正確に把握して、その観点からパフォーマンスを評価するというポイントは普遍的であると筆者は考える。今後Flash／SSDドライブの普及などさまざまな技術革新により、個々の評価値は変わるであろうが、この考え方自体は変化しないはずだ。
本稿がI/Oパフォーマンス分析の一助となることを期待する。
弓削 賢太
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
メインフレーム・センター 第一テクノロジー
アドバイザリーITスペシャリスト
著者プロフィール
弓削 賢太 氏 ／2007年、日本IBM入社。2011年より日本アイ・ビー・エム システムズ・エンジニアリングへ出向し、System zの製品技術支援を担当。2014年よりIBMエンタープライズ・ストレージ DS8000シリーズの技術支援を担当し、主にDS8000 Copy Service機能を用いた災害対策ソリューションやパフォーマンス分析の技術支援に従事。
［IS magazine No.13（2016年9月）掲載］
