SysAdmin's Group システム管理者の会
日本最大規模の
システム管理者のネットワーク

運用ノウハウを学ぶ

システム管理に関わるベーシック情報やトレンドをご案内します!

富士通メインフレームの本質を見る~性能改善の現場 第2回 A社での事例(2)~自信を持たせる
2008年10月29日 11:11

2.1 性能評価・改善のプロセス

 GSを担当しているメーカのSEでさえ性能評価・改善の手順や手法を知らないのが実状です。そこで、最初に図3に示す性能評価プロセス(左)と使用する性能データ(右)を一通り説明し、作業の進め方を検討しました。ポイントは以下の3点と考えています。

    • ①~④では現状分析を網羅的に行い、必要に応じて詳細分析を行うこと
    • 根本原因を究明し、適切な課題設定⑤を行うこと
    • 効果的な改善を行い、⑤~⑫のサイクルを効率よく回すこと
 (※改善作業はお客様またはSEが行います。)
081029_1.png
図3 性能評価プロセスと性能データ
網羅的な現状分析とは、システム、オンライン処理、バッチ処理及びその他の処理について、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はデータフォーマットがマニュアルに公開されているだけで、編集するプログラムはほとんど提供されていません。基本的なレコードタイプはシステム標準で取得されています。

2.2 性能評価・改善プロジェクトの進め方(第1、2フェーズ)
 性能評価・改善プロジェクトは4つのフェーズで実施しました。
image07.PNG
【第1フェーズ】
導入フェーズであり、以下の3点をできるだけ迅速に行います(2週間程度)。

    • 必要な性能データをいつでも取得・分析ができる環境を整備する
        • 図3右のSMF98(SymfoWARE/RDBの情報)、AIM課金統計情報(トランザクションに関する情報)、STF0ト   レース(OSの内部トレース)の準備
        • システムの状況をふまえ採取できないデータを見極める
    • PDL、SMFを広く浅く、システムを俯瞰するように分析する
        • バッファやログ環境の使用状況、バッチジョブの稼動状況(図4)
    • 業務処理の動きを性能データから把握し、お客様と情報を共有する
081029_2.gif
図4 バッチジョブの稼動状況
【第2フェーズ】
第2フェーズに入ると新しい発見や具体的な改善策が見えてきます(2週間程度)。

データベースごとのアクセス状況(データベースを軸とする)
重要なデータベースについてアクセス回数、排他待ち回数・時間、バッファの使用状況、デッドロックの情報を把握する重要なデータベースについてアクセス回数、排他待ち回数・時間、バッファの使用状況、デッドロックの情報を把握する
データベースアクセスの多いプログラム(プログラムを軸とする)
性能上問題になりそうなプログラムとその影響度を把握する
I/Oの多いファイル など
実施の可否は別にして、改善項目案は10個を超えます。詳細分析から改善に導かれた実例を2.3に紹介します。

2.3 自信を持たせる

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

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


 さっそくSTF0トレースを採取し、プログラムの動きを分析したところ、あるデータベースのテーブルに777回、インデックスに44回の実I/Oを発行していることがわかりました。平均I/O時間は2msだったので、データベースアクセスだけで3秒以上(CPU時間を含む)かかっています。
このデータベースへのアクセス方法を確認したところ、数10件のレコードしか読まないはずだということがわかりました。
(※オンライン画面を見せてもらってからここまでかかった時間は1時間程度です。)

 後ほどプログラムソースを確認して頂いたところ、データベース検索の終了方法にミスが見つかったとの報告を受けました。後日プログラムを修正し、レスポンス時間は1秒以内に改善されました。この改善効果にはお客様自身もびっくりされていました。
 プログラム改修はできるだけ行わないようにしていますが、影響範囲が小さく、簡単に直せ、かつ効果が大きいような案件はお客様の判断に任せ随時対応してもらっています。目に見えて性能が改善するのはうれしいもので自信にもなります。

 この例で、お客様が遅い処理を動かしてくれたことは幸運だったとともに、私自身、現場、現物を大事にしなければならないことを痛感しました。

 前回紹介した「データを見ただけ」の仮説は一箇所修正することになりました。
仮説:原因はデータベースの排他待ちだろうが、原因の特定が最初の課題。
⇒ オンライン処理自身の性能の検証・改善及び排他待ちの削減が課題。

 次回は、A社での事例(3)~実現した性能改善 を紹介します。

                                                   以 上
運用研究レポート
富士通メインフレームの本質を見る~性能改善の現場

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

記事一覧へ
筆者紹介

有賀 光浩(ありが みつひろ)



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

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

  • 新着Q&A
  • 最新の回答
回答数:22019年11月12日

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

毎年恒例となった「システム管理者の会」の年に一度の大イベントとなる「システム管理者感謝の日イベント」の模様をお届けします。 今年のテーマは、「集まれ若いチカラ!システム管理者のための夏期講習!!」です。

個人情報保護方針
運営者につい て
利用規約
サイトマップ