概要
SEが何ヶ月も調査しているはずなのに一向に解決しない性能問題。ギブアップ寸前の問題の相談を受け、解決に導いていくプロセスを現場の視点で紹介します。性能改善の現場ではメインフレームの本質が見えてきます。
4.1 背景
4.2 事前の状況把握
毎度のことですが、お客様との最初のミーティング前にPDL/PDAを入手し、システムの特徴を把握することにしました。PDLは毎日15分間を6回採取しているようです。
4.3 性能データの再調査
図7と見比べて下さい。なんとCPU使用率はVMの設定値である200%でほぼ頭打ちになっています。IOPSは類似しているので、システムの稼動状況は似ています。異常値と思っていた日中のCPU頻度も40前後に落ち着いています。
さて、何が起きたのでしょうか?
CPU使用率は図9が正しく、図7は間違っています。
この現象はMSP特有のもので、AVM配下で従来の方式(OSによるサンプリング方式)でPDLを採取するとCPU使用率の「精度が落ちる」とマニュアルにもしっかりと記載されています。この違いを頭では認識しているのですが、参考程度の軽い気持ちでデータを見てしまいがちです。
事前の調査は残念ながら違った結果になりました。
今回のプロジェクトでまず最初に行ったことはCPU使用率の再確認で、お客様には事実と原因、改善方法をしっかりと理解して頂きました。アウトソーサにはお客様から伝えてもらっています。
元々の問題であった、メッセージの滞留、タイムアウトについては、図8のオンラインレスポンスの悪い状況と関係しています。この改善プロセスは次回紹介します。夜間バッチの遅延については、図9からCPU頻度が高いことが原因の一つと想定されます。これは次々回に紹介します。
システム統合の流れからAVMを使う運用が増えています。御社のシステムでも同様の誤解をしている可能性があります。特に、性能データを加工するツールを使われているときは、データの出所を確認することをお勧めします。
注)XSPはAVM配下でも問題ありません。
4.4 学び
私たちは性能データを過信することがあります。精度はデータの種類、パラメタまたシステム環境によっても変わります。そのため、2つ以上の異なるデータを使い精度を確認する慎重さが必要です。
今回のケースから、PDLのCPU使用率はSDM(System Decision Manager)レポートのCPUサービス量と相互確認しています。
以 上
連載一覧
筆者紹介
株式会社アイビスインターナショナル 代表取締役
1963年生まれ。1985年富士通株式会社入社。1992年~2003年まで社内共通技術部門で国内外のメインフレームの性能コンサルティングを実施、担当したシステム数は1,000を超える。2000年からは大規模SIプロジェクトへの品質コンサルティング部門も立ち上げた。
2004年に株式会社アイビスインターナショナルを設立。富士通メインフレームの性能コンサルティングとIT統制コンサルティングを行っている。
技術情報はhttp://www.ibisinc.co.jp/で公開中。富士通やSI’erからのアクセスが多い。
当サイトには、同名シリーズ「富士通メインフレームの本質を見る~IT全般統制の考え方」を3回、「富士通メインフレームの本質を見る~バッチ処理の性能評価と改善事例から」を6回、「富士通メインフレームの本質を見る~CPUリプレースの考え方」を3回、「富士通メインフレームの本質を見る~性能改善の現場」を7回、「富士通メインフレームの本質を見る~2009年度の最新トッピックス」を3回、「富士通メインフレームの本質を見る~2008年度の最新トピックス」を2回にわたり掲載。
コメント
投稿にはログインしてください