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

運用ノウハウを学ぶ

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

富士通メインフレームの本質を見る~性能改善の現場 第1回 A社での事例(1)~初期動作
2008年09月24日 10:52

1.1 背景
 A社担当のディーラSEから最初の問合せがあったのが2年以上前。その間、お客様とSEが少しずつチューニングを行ってきたようです。お客様の業績がよく、「売上が1.5倍になったときシステムが業務に影響を与えないための改善を早急に行いたい」というのが依頼の主旨でした。

販売系を中心とした業務でプログラムは3,500本以上、CPUはGSの中型機、OSはXSP、データベースはSymfoWARE/RDBです。

1.2 事前の状況把握
 運良く、最初のミーティング前に以下の資料を入手することができました。

チューニングの経緯
SEが調査した性能評価報告書
システム構成図
性能評価の元になった性能データPDL/PDA(数日分)
 最初に見るのはPDL/PDAです。まず、パラメタが適当か、データをロストせず取得できているかを確認します。

 10数年前は100ページ以上のリストを1ページ目からパッパと素早くめくり、なるほどねと呟きながら見ていました。今はPC上で独自ツールを使い、短時間かつ網羅的に一次分析をすることができます。私が愛用している3点セットを紹介します。

080924_1.png
図1 システムの稼動状況とCPU/IO頻度分析

図1左のグラフはCPU使用率(棒グラフ)とIOPS(折線グラフ;1秒当たりのI/O回数)を表したものです。CPU使用率は20%前後と低く、16時頃と20時頃に一時的な高負荷があることがわかります。PAGE INは0なのでページングは発生していません。

  図1右のグラフは前回紹介したCPU/IO頻度分析で縦軸のIOPSは左のグラフと同じです。半数以上はCPU/IO頻度の標準値(20~40)に分布していますが、CPUが高負荷の2箇所はCPU頻度が高い(40以上)ことがわかります。SymfoWAREを使っているので全体的にCPU頻度は若干高いが、アプリの性能品質は悪くないと評価しました。

  システム全体のIOPSは200以下なのでシステムの規模は小さく、物理的にもDASDネックは起きにくいと判断しています。
080924_2.gif
図2 オンライン業務の稼動状況

図2はオンライン業務の稼動状況を一目でわかるようにした図です。赤くて(最大処理時間が30秒以上)大きい円(稼働率が高い)があると問題です。図の中央に円が4つ重なっていますが、平均処理時間(横軸)も0.2秒程度で大きな問題はなさそうです。見えにくいのですが、右下には赤い円が1つ、ピンクの円が2つあります。

  この他にバッファの使用状況やボトルネックなどのチェックをかけます。

  以上のようにシステムを客観的に見ると、小さな問題はいくつかありますが大きなボトルネックは見当たらず、平均点以上にきれいに動いていると判断しました。

  この結果をふまえて、チューニングの経緯や性能評価報告書に目を通します。お客様やSEがどんな価値観を大切にして改善に取り組んできたのかをイメージします。

1.3 問題と仮説構築
最初に一般論をお話しします。問題とは目標と現実とのギャップであり、性能上の代表的な問題は「遅い」ことです。(「速い」ことも問題となります。)「遅い」には以下のようなケースが考えられます。

   ①性能目標値と比べて遅い ・・・ 【現在-目標値】目標値があることが稀
   ②目標値はないが初めから遅すぎる ・・・ 【現在-常識】今からでも目標を設定する
   ③前より遅くなった ・・・ 【現在-前】前のデータが残っていることはほとんどない
   ④遅いときがある ・・・ 【遅いとき-普通のとき】今から測定できる
   ⑤Aと比べてBが遅い ・・・ 【B-A】今から測定できるかもしれない
 一番多く最もやっかいなケースが前のデータが存在しない③です。そんなときは慌てず騒がず、まず5W1Hで整理しましょう。

      • (Who)だれが遅くなったと言っているのか?
      • (Where)その人はどこにいるのか?
      • (What)何から何までの時間が遅いのか?
      • (How)どのくらい遅くなったのか?
      • (Why)なぜ遅くなったことに気付いたのか?
      • (When)いつ頃遅くなったのに気付いたのか?
 私が経験したHowの最短は、ダム端末で入力しているオペレータの方のタイミングが一瞬ずれるという0.1秒以下のものでした。これは非常にむずかしい問題です。

  10分だった処理が20分くらい遅くなってくれれば、現在を適切に分析することで問題を想像することができるかもしれません。

  次に、前と現在との環境変化を整理する必要があります(表1)。メーカにとって一番困るのはCPUを移行して遅くなるケースでしょう(でした)。CPUの特性上、本当に遅くなることもあり得ますから、どんな手段を使っても性能を改善するしかありません。
表1 環境の変化の例
image06.PNG
さて、現場に戻します。今回、お客様からの指摘事項は3件で各々仮説をたてました。

      • 売上が1.5倍になってもシステムは安定稼動できるか
            •  ⇒ 問題③の未然防止
            •  仮説:図1からCPU、メモリは問題ない。業務アプリの処理能力向上が課題。
      • 通常1秒かからない受注、売上処理のレスポンスが、集配信処理が動くと数秒になる
            •  ⇒ 問題④
            •  仮説:原因はデータベースの排他待ちだろうが、原因の特定が最初の課題。
      • データベース設計の根本的な問題を改善したい
            •  ⇒ 問題②をお客様とSEで改善してきた
            •  仮説:お客様自身がデータベースの性能設計を理解することが課題。
 環境の変化ですが、最近のGSでは珍しい業務量の増加です。 この段階で本案件は単純なシステムチューングでは解決せず、業務アプリやデータベース設計に首を突っ込む覚悟が必要と判断しています。

  この状況でチューニングに過大な期待をすることは危険であり、今後の性能改善についてお客様に次のようにお伝えしました。

  今までの「数秒~10秒の改善」から今後は一桁小さい「1秒の改善」が要求されています。この性能改善を効果的かつ効率的に実施するには「もぐら叩きの対応」、「経験と勘による対応」から脱却しなければなりません。即ち、網羅的かつ詳細なデータ解析を行い、根本原因を追究し、戦略的に対策を打つことが重要です。つきましては、性能評価プロセスに沿って作業を進めることをご提案します。

 次回は、A社での事例(2)~自信を持たせる を紹介します。

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

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日

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

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

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

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