2020.05.13
#7 オンライン遅延の分析事例
MFシリーズ編
![](https://www.iim.co.jp/hubfs/IIM/TechReport/9.jpg)
目次
開く
一般的なコンピューターシステムでは様々な業務を稼動させていますが、大別するとバッチ、オンライン、端末に分類できます。その中でもオンライン業務は多くの方々が利用されているため、遅延が発生すると大きな影響を及ぼします。今回は重要業務であるオンライン遅延についてメインフレーム向け性能管理ソフトウェア ES/1 NEO MFシリーズを活用した分析事例をご紹介します。
現象
オンラインが遅延している時間帯にトランザクション数は増加していないが、特定のオンライン業務のレスポンス時間が遅くなります。
調査
先ずは状況を確認するため、オンラインのレスポンス時間とトランザクション数を通常日と遅延日とで比較したところ、特定のオンライン業務のレスポンス時間は大幅に悪化しており、特に午前中はオンラインのレスポンス時間が3秒以上になっている時間帯があります。(図1)
![7_1](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_1.jpg?width=1000&name=7_1.jpg)
![7_1](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_1.jpg?width=1000&name=7_1.jpg)
図1:オンラインのレスポンス時間
トランザクション数は通常日と遅延日に大きな変化はないです。(図2)
![7_2](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_2.jpg?width=1000&name=7_2.jpg)
![7_2](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_2.jpg?width=1000&name=7_2.jpg)
図2:オンラインのトランザクション数
次にCPU、メモリー、ディスクについて確認します。CPU使用率は遅延日の方が若干高くなっていますが、最も使用率が高い時間帯でも40%以上の余力があります。(図3)
メモリーは書面上割愛しますが、メモリー使用率に変化はなく、過負荷を判定するページングは発生していない状況です。
![7_3](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_3.jpg?width=1000&name=7_3.jpg)
![7_3](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_3.jpg?width=1000&name=7_3.jpg)
図3:CPU使用率
負荷の高いディスクボリュームは偏りはありますが、ディスクのレスポンス時間は3ミリ秒以下で良好です。(図4)
![7_4](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_4.jpg?width=1000&name=7_4.jpg)
![7_4](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_4.jpg?width=1000&name=7_4.jpg)
図4:ディスクボリュームの負荷率とレスポンス時間
問題となるようなディスクボリュームが発見できなかったため、遅延時間帯にアクセス回数が増加しているディスクボリュームがないか調査すると、アクセス回数が増加したディスクボリュームがありました。オンラインが遅延している時間帯、該当ボリュームのアクセス回数が1秒当たり500回以上発生しています。(図5)
![7_5](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_5.jpg?width=1000&name=7_5.jpg)
![7_5](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_5.jpg?width=1000&name=7_5.jpg)
図5:特定ディスクボリュームのアクセス回数
遅延したオンライン業務のレスポンス時間とアクセス回数が増加したディスクボリュームを確認すると顕著な相関があります。(図6)
![7_6](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_6.jpg?width=1000&name=7_6.jpg)
![7_6](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_6.jpg?width=1000&name=7_6.jpg)
図6:ディスクボリュームのアクセス回数とオンラインのレスポンス時間
考察
オンラインレスポンスが悪化した時間帯に特定ディスクボリュームのアクセス回数が増加していたことから、遅延したオンライン業務で使用するファイルが該当ボリュームに含まれているか確認したところ、該当ボリュームはオンラインで使用するデータベースのインデックスが入っていました。
分析結果を受けて、該当ボリュームに含まれていたデータベースについてお客様側で調査したところ、対象インデックスのエクステントが増加していることが判明しました。この事から、断片化により、無駄なI/Oが増加したことで、オンラインのレスポンス時間が遅延したと考えられます。
チューニング後
該当インデックスの再創成を実施したところ、データベースが入っているディスクボリュームのアクセス回数が減少し、オンラインの遅延は解消されました。(図7)
![7_7](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_7.jpg?width=1000&name=7_7.jpg)
![7_7](https://www.iim.co.jp/hs-fs/hubfs/IIM/TechReport/No.7/7_7.jpg?width=1000&name=7_7.jpg)
図7:オンラインのレスポンス時間と特定ディスクボリュームのアクセス回数
まとめ
今回の場合、ディスクボリュームのレスポンス悪化ではなく、アクセス回数の増加から問題発見に至りましたが、先ず分析する際は、リソースの3要素であるCPU、メモリー、ディスクの各種項目を確認します。その場合、基本的なことですが、遅延日だけではなく通常日と比較することで違いを見つけ、リソースが特定できればその詳細を調査することにより、問題分析の手掛かりになることがあります。
今回ご紹介した内容が今後のパフォーマンス管理に少しでもお役に立てば幸いです。
![](https://www.iim.co.jp/hubfs/IIM/%E3%83%96%E3%83%AD%E3%82%B0/%E5%9F%B7%E7%AD%86%E8%80%85/%E5%9F%B7%E7%AD%86%E8%80%85-3.png)
執筆者
T.E.
営業技術本部 技術サービス統括部 技術サービス2部
お客様担当SEとして、製品の構築から活用方法までの一連のサポートを担当
また、お客様環境にて性能問題が発生した際には、製品のアウトプットを利用し、問題解決に向けた調査/提案業務を実施
■経歴
1994年 入社
1995年~ 西日本でのお客さまサポートを担当
主にES/1 MFシリーズを利用したシステムリソース情報からの性能管理サポートに従事
関連記事
-
#21 Webサイトにアクセスして画面表示されるまで
2024.06.21
#Dynatrace
#ユーザー体感
#レスポンス
ブラウザで画面をクリックして画面が表示されるまでの動作についての解説と、Dynatrace RUMを利用した端末サイドの分析例を紹介します。
-
#20 Dynatraceを用いたKubernetes分析(3/3)
2024.05.14
#Dynatrace
#Kubernetes
IT運用の現場では、インフラ構成の選択肢としてKubernetes環境が一般的となりつつあります。今回は「Dynatraceを用いたKubernetes分析」を主軸に、3本の記事構成でご紹介します。 3本目は、アラート機能に焦点を当てて、各種設定やIT運用にどのように役立てられるのかを説明します。
-
#19 Dynatraceを用いたKubernetes分析(2/3)
2024.05.14
#Dynatrace
#Kubernetes
IT運用の現場では、インフラ構成の選択肢としてKubernetes環境が一般的となりつつあります。今回は、「Dynatraceを用いたKubernetes分析」を主軸に、3本の記事構成でご紹介します。 2本目は、パフォーマンス分析の観点から、Dynatraceの各画面や手法を紹介します。