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

運用ノウハウを学ぶ

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

富士通メインフレームの本質を見る~性能改善の現場 第3回 A社での事例(3)~性能改善
2008年11月26日 11:35


3.1 性能評価・改善プロジェクトの進め方(第3、4フェーズ)
 性能評価・改善プロジェクトは4つのフェーズで実施しています。(再掲)
image08.PNG
第1~2フェーズで、重要なオンラインプログラムのレスポンス時間・バッチプログラムの処理時間の分布を表2のように整理しました。2秒以上で明らかな排他待ちは1箇所だけで(プログラムxxx0011の2~3秒)、その他は全て自身の処理で時間がかかっていることとその原因がわかりました。
081126_1.png
表2 レスポンス・処理時間の分布(改善前)
【第3フェーズ】
最優先課題は重要なプログラム自身の処理時間の短縮と設定し、改善は3つの方針で進めました。

① プログラム、データベースそしてシステムの3方向から具体策を考える
② 重要なプログラムやデータベースを優先して対応する
③ どうしてそうなるのか、お客様に理屈を徹底して理解して頂く

【補足説明】
性能改善の全体像を図5に紹介します。直接的な処理時間を改善することにより(上)、二次的な資源待ちによる遅延を改善します(下)。

①は以下のように対応しています。

    • プログラム(上-左のプログラムロジック)
        • ・・・前回2.3で紹介したようなプログラムロジックの改善
    • データベース(上-右のDBMS依存)
        • ・・・無駄をなくす(削除済レコード、オーバフロー、ページ分裂など)
        • 排他の範囲を狭くする(特にインデックス)
        • メモリ常駐の検討
    • システム(下-中央~右の点線で囲んだ部分)
        • ・・・適切なCPU優先順位を設定する(特に、排他待ちを誘発するバッチ処理)


081126_2.pngのサムネール画像
図5 性能改善の全体像

具体的な改善項目は、大小合わせて20を超えています。
 前回2.3で紹介したプログラム(xxx0001)のロジック改善では、データベースの不要な排他待ちが削減され、デッドロックも起きにくくなり、システム全体の性能が大幅に改善される結果となりました。

【第4フェーズ】

 重要なプログラムについては性能モデルを作成します。例えば、上記プログラムの性能改善の前後だと図6のようになります。データベースのメモリ常駐化も行っているためCPU/IO頻度は20→42に上昇しています。

081126_3.png

図6 性能モデル

本題である「売上が1.5倍になったときシステムが業務に影響を与えない」ことを検証すためには様々な考慮が必要です。

① 売上の伸びとシステムの資源使用量の関係
 CPUは第1回の図1に示したとおり十分に余裕があるので、売上との厳密な関係を導く必要はありませんでした。I/Oやメモリについても検証をします。

② システムで最初にボトルネックとなる資源は何か
 CPUだけとは限りません。本件では、ほとんどのプログラムが参照しているデータベースがあり、できるだけ排他待ちが起きないようにする必要がありました。お客様にはデータベースの構造や排他制御の仕組みを十分に理解して頂き、自ら考え、チューニングを実施して頂きました。

③ 多重処理が可能か
 入力端末やバッチジョブの実行多重度を増やすために、タスク数や優先度の調整を行います。

④ どこまで遅くなってよいのか
 ハードの性能を上げない限り処理時間は遅延します(図6の待ち時間が延びる)。現実的なサービスレベルを合意することが重要です。

更に、想定されるリスクについてもお客様と意識を合わせることが重要です。例えば、処理時間が予想以上に遅延してしまったときの対処方法など具体的に提示します。

3.2 改善結果

 表2に示した状況から2週間後の改善結果を表3に示します。遅かった処理が短期間で改善している様子がわかると思います。

081126_4.png

表3 レスポンス・処理時間の分布(改善後)
3.3 まとめ
何ヶ月も調査しているのに解決しない原因の一つは、調査の仕方を知らないからです。思いつきで改善作業を進めた結果、先の見えないもぐら叩きの状態に陥っている可能性もあります。

ギブアップ寸前でも相談をしてくれれば必ず解決の方向に向かっていきます。残念ながら、放置されているシステムがあるのも現実です。

性能改善は現場で行います。私たちが提示した性能改善案も現場と乖離があると、全く実施してもらえないこともあります。根の深そうなトラブルを対応するときには、現場を見て、話しをすることが基本と考えています。本質的な話しをするために、私たちがまず最初にやるべきことはデータを正確に分析することです。

豊富なデータが提供され、広く深く分析できるのがメインフレームの強みです。

 次回は、性能改善の現場-B社での事例を紹介する予定です。

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

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日

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

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

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

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