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

第2回　A社での事例（2）～自信を持たせる

概要

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

目次
２．１　性能評価・改善のプロセス
２．２　性能評価・改善プロジェクトの進め方（第１、２フェーズ）
２．３　自信を持たせる

２．１　性能評価・改善のプロセス

　GSを担当しているメーカのSEでさえ性能評価・改善の手順や手法を知らないのが実状です。そこで、最初に図３に示す性能評価プロセス（左）と使用する性能データ（右）を一通り説明し、作業の進め方を検討しました。ポイントは以下の３点と考えています。 ①～④では現状分析を網羅的に行い、必要に応じて詳細分析を行うこと 根本原因を究明し、適切な課題設定⑤を行うこと 効果的な改善を行い、⑤～⑫のサイクルを効率よく回すこと （※改善作業はお客様またはSEが行います。）

図３　性能評価プロセスと性能データ
網羅的な現状分析とは、システム、オンライン処理、バッチ処理及びその他の処理について、PDL/PDA、SMFといった性能データを使って行います。
　性能データについて簡単に紹介します。
　PDL(Performance Data Logger)はGSで最も代表的な性能データです。リソースの使用状況のほかサブシステムの稼動状況など、MSPは39種類、XSPは19種類のデータを採取できますが、通常使用するのは半分くらいです。PDLは必要なときにユーザが実行する必要があります。
　PDA(Performance Data Analyzer)はPDLを編集するプログラムです。MSPは53種類、XSPは25種類のレポートが出力できます。 
　SMF(System Management Facility)には主にシステムの運用状況が取得されています。MSPは79種類のレコードタイプ、XSPは53種類のレコードタイプがあります。SMFはデータフォーマットがマニュアルに公開されているだけで、編集するプログラムはほとんど提供されていません。基本的なレコードタイプはシステム標準で取得されています。
 

２．２　性能評価・改善プロジェクトの進め方（第１、２フェーズ）

性能評価・改善プロジェクトは4つのフェーズで実施しました。

【第1フェーズ】
導入フェーズであり、以下の３点をできるだけ迅速に行います（２週間程度）。
 
必要な性能データをいつでも取得・分析ができる環境を整備する
図３右のSMF98（SymfoWARE/RDBの情報）、AIM課金統計情報（トランザクションに関する情報）、STF0トレース（OSの内部トレース）の準備
システムの状況をふまえ採取できないデータを見極める
PDL、SMFを広く浅く、システムを俯瞰するように分析する
バッファやログ環境の使用状況、バッチジョブの稼動状況（図４）
業務処理の動きを性能データから把握し、お客様と情報を共有する
 
図４　バッチジョブの稼動状況
【第2フェーズ】
第２フェーズに入ると新しい発見や具体的な改善策が見えてきます（２週間程度）。
 
データベースごとのアクセス状況（データベースを軸とする）
重要なデータベースについてアクセス回数、排他待ち回数・時間、バッファの使用状況、デッドロックの情報を把握する重要なデータベースについてアクセス回数、排他待ち回数・時間、バッファの使用状況、デッドロックの情報を把握する
データベースアクセスの多いプログラム（プログラムを軸とする）
性能上問題になりそうなプログラムとその影響度を把握する
I/Oの多いファイル　など
実施の可否は別にして、改善項目案は10個を超えます。詳細分析から改善に導かれた実例を２．３に紹介します。
 

２．３　自信を持たせる

実際に使っているオンライン業務のオペレーションを見せてもらったところ、４秒くらい返ってこない処理がありました。Ａ（有賀）とＵ（お客様）の会話です。

Ａ 「今の画面、何の処理ですか？」
Ｕ 「問題になっているｘｘ業務の照会処理です」
Ａ 「もう一度できますか？」
Ｕ 「はい・・・、やはり４秒くらいかかりますね」
Ａ 「どうして今そんなに遅いのでしょう？　バッチ処理との排他待ちですか？」
Ｕ 「いや、バッチ処理は今実行されていないと思います」
Ａ 「本番環境でトレースを採取して動きを分析したいのですができますか？」
Ｕ 「確認しますが、問題ないと思います」

 
　さっそくSTF0トレースを採取し、プログラムの動きを分析したところ、あるデータベースのテーブルに777回、インデックスに44回の実I/Oを発行していることがわかりました。平均I/O時間は２msだったので、データベースアクセスだけで３秒以上（CPU時間を含む）かかっています。
このデータベースへのアクセス方法を確認したところ、数10件のレコードしか読まないはずだということがわかりました。
（※オンライン画面を見せてもらってからここまでかかった時間は１時間程度です。）
 
　後ほどプログラムソースを確認して頂いたところ、データベース検索の終了方法にミスが見つかったとの報告を受けました。後日プログラムを修正し、レスポンス時間は１秒以内に改善されました。この改善効果にはお客様自身もびっくりされていました。
　プログラム改修はできるだけ行わないようにしていますが、影響範囲が小さく、簡単に直せ、かつ効果が大きいような案件はお客様の判断に任せ随時対応してもらっています。目に見えて性能が改善するのはうれしいもので自信にもなります。
 
　この例で、お客様が遅い処理を動かしてくれたことは幸運だったとともに、私自身、現場、現物を大事にしなければならないことを痛感しました。
 
　前回紹介した「データを見ただけ」の仮説は一箇所修正することになりました。
仮説：原因はデータベースの排他待ちだろうが、原因の特定が最初の課題。
⇒　オンライン処理自身の性能の検証・改善及び排他待ちの削減が課題。
 
　次回は、Ａ社での事例（3）～実現した性能改善　を紹介します。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以　上

連載一覧

コメント

筆者紹介

有賀　光浩（ありが　みつひろ）

株式会社アイビスインターナショナル　代表取締役

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

バックナンバー