分析事例

原因不明のレスポンス遅延分析

SIerが半年かかっても特定できなかった遅延原因をわずか数分で特定し、チューニングにより問題解決

オープンシステム向け性能管理ソフトウエア 「ES/1 NEO CSシリーズ」導入事例

きっかけ：レスポンス遅延の発生

お客様の顧客管理システムにおいて、レスポンス遅延が発生して利用者よりクレームが寄せられました。

 

 

システム部門の対応：原因が究明できず、性能劣化が慢性化

ハードウェア保守とDBの開発を担当している別会社とも協力し調査をしましたが、原因が分からず半年が経過してしまいました。そこで、IIMに分析をご依頼いただきました。

 

 

IIMによる性能評価：①チューニングヒントによる原因の推測

対象システムは、Webサーバー、APサーバー、DBサーバーの3層構成からなっているため、問題がどこで発生しているかを切り分けるために、ES/1 NEO CSシリーズにて、ピーク日における各サーバのチューニングヒントを確認しました。

 

その結果、DBサーバーにてデバイスEのビジー率が非常に高い状態になっていることが判明しました。（図1）
bunseki_01_01
bunseki_01_01

図1：DBサーバーのチューニングヒント

そこで、デバイスEに何らかの問題があると推測して、さらに詳細に分析を実施しました。

 

 

IIMによる性能評価：②相関判定による原因の特定

デバイスEと関連がある項目を洗い出して原因を特定するために相関判定機能にて調査したところ、以下の項目に相関関係があることが分かりました。（図2）

 

デバイスEのアクセス回数

テンポラリ用Oracleデータファイル（TEMP01.DBF）のアクセス回数

bunseki_01_02
bunseki_01_02

図2：相関判定

グラフでTEMP01.DBFへのアクセス回数を確認したところ、テンポラリファイルへの実I/Oは少ないことが望ましいのですが、読み込み、書き込みともに非常に多くなっていることが確認できました。（図3）
bunseki_01_03
bunseki_01_03

図3：Oracleデータファイル毎のアクセス回数

以上より、TEMP01.DBFへの実I/Oの増加が原因でデバイスEの使用率が上昇しアクセス待ち時間が長くなったことでレスポンス悪化が発生したと結論付けました。

 

解決策として、TEMP01.DBFへの実I/Oが発生せずメモリ内で処理が完了できるように、初期化パラメータのsort_area_sizeを大きくすることをご提案しました。

 

 

結果：レスポンス悪化の解消

sort_area_sizeを512KBから1024KBに拡大したところ、レスポンスの悪化は解消されました。
効果測定として、ピーク日について前後比較を実施したところ、TEMP01.DBFへの実I/Oが削減されていることが確認できました。（図4）
bunseki_01_04
bunseki_01_04

（図4：Oracleデータファイル毎のアクセス回数［チューニング後］

まとめ

専門知識が豊富なSIer様で半年間分析しても解決に至らなかった問題が、数分の分析で原因を特定するだけでなく、解決策まで提示することができたことで、SIer様とエンドユーザー様にIIMの技術力の高さをご評価いただきました。

関連製品

関連事例