富士通メインフレームの本質を見る~性能改善の現場

第4回 B社での事例(1)~性能データの誤差

概要

SEが何ヶ月も調査しているはずなのに一向に解決しない性能問題。ギブアップ寸前の問題の相談を受け、解決に導いていくプロセスを現場の視点で紹介します。性能改善の現場ではメインフレームの本質が見えてきます。

性能改善を登山に例えることがあります。同じ山頂(目標)を目指していても登山のルート(改善方法)はいくつもありますし、人それぞれ得意なスタイルもあります。時間が無いときには途中まで交通手段(ハードの増強)を使います。油断や判断ミスをすると大怪我をすることもあります。経験を積めば積むほど周りの環境に注意を配り、基本に忠実になることが重要です。
 
今回はB社の性能評価・改善事例を紹介します。最終的には成功に終わったのですが、そのプロセスは決して順風満帆ではありませんでした。ここでは直面した問題を中心に話しを進めます。
 
目次
4.1 背景
4.2 事前の状況把握
4.3 性能データの再調査
4.4 学び

4.1 背景

 20年以上前から稼動している基幹システムですが、最近メッセージの滞留による異常終了、サーバ間のタイムアウト、夜間バッチの遅延などが発生しているようです。今後10年間使えるシステムを目指し、抜本的な改善への協力依頼がありました。
 
 アプリ総資産はCOBOL、YPS、アセンブラで2Mstep以上、CPUはGSの超大型機をAVMを使って3つの仮想システム(VM)に分割して使用しています。OSはMSP、データベースはNDBとVSAMが中心です。アプリ開発はお客様が担当し、運用はアウトソーシングをしています。
 

4.2 事前の状況把握

 毎度のことですが、お客様との最初のミーティング前にPDL/PDAを入手し、システムの特徴を把握することにしました。PDLは毎日15分間を6回採取しているようです。

図7 システムの稼動状況とCPU/IO頻度分析(事前調査)
図7左のグラフはCPU使用率(棒グラフ)とIOPS(折線グラフ;1秒当たりのI/O回数)を表したものです。4CPUモデルなのでCPU使用率の最大は400%となっています。対象VMにはCPUを200%割り当てていますが、他のVMがCPUを使っていないときは空いているCPUを自由に使うことができます(AUTOMATICモード)。日中のCPU使用率は設定値の200%をはるかに越え、400%に近づいていることがわかります。これは明らかにCPU過負荷の状態です。
 
 図7右のグラフはCPU/IO頻度分析ですが、日中は非常にCPU頻度が高く、夜間は統一性が見られないことがわかります。今まで見たことがないような異常値です。
図8 オンライン業務の稼動状況
図8はオンライン業務のレスポンス分布です。赤くて(最大処理時間が30秒以上)大きい円(稼働率が高い)があると問題ありなので、このシステムはかなり大問題だということがひと目でわかります。
 
 以上よりシステムの状況はよろしくないことが理解できました。反面、異常値が多いのでCPU頻度の高い事象をいくつか改善すればシステム全体の性能向上につながるかもしれないと期待しています。
 

4.3 性能データの再調査

 上記の調査結果をお客様にご説明した上で、改めて性能データを取得するお願いをしました。ポイントは3点で、①24時間継続して取得すること、②AVM配下でより正確な情報を取得する機能を使うこと、③採取データの見直しです。
 
 PDLはアウトソーサが利用していたため(前述の通り毎日15分間×6回を集計していた)、お客様から一時的な運用変更依頼をかけました。しかし、何かが気にさわってしまったようで、変更理由を一つ一つ説明をし、やっとのことで対応してもらえました。
 
 性能データの調査結果を図9に示します。
図9 システムの稼動状況とCPU/IO頻度分析(再調査)

図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回にわたり掲載。

バックナンバー