- 目次
- １．１ 背景
- １．２ 事前の状況把握
- １．３ 問題と仮説構築
１．１ 背景
A社担当のディーラSEから最初の問合せがあったのが2年以上前。その間、お客様とSEが少しずつチューニングを行ってきたようです。お客様の業績がよく、「売上が1.5倍になったときシステムが業務に影響を与えないための改善を早急に行いたい」というのが依頼の主旨でした。 販売系を中心とした業務でプログラムは3,500本以上、CPUはGSの中型機、OSはXSP、データベースはSymfoWARE/RDBです。
１．２ 事前の状況把握
運良く、最初のミーティング前に以下の資料を入手することができました。
チューニングの経緯
SEが調査した性能評価報告書
システム構成図
性能評価の元になった性能データPDL/PDA（数日分）
最初に見るのはPDL/PDAです。まず、パラメタが適当か、データをロストせず取得できているかを確認します。
10数年前は100ページ以上のリストを1ページ目からパッパと素早くめくり、なるほどねと呟きながら見ていました。今はPC上で独自ツールを使い、短時間かつ網羅的に一次分析をすることができます。私が愛用している3点セットを紹介します。
図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が高負荷の２箇所はCPU頻度が高い（40以上）ことがわかります。SymfoWAREを使っているので全体的にCPU頻度は若干高いが、アプリの性能品質は悪くないと評価しました。
システム全体のIOPSは200以下なのでシステムの規模は小さく、物理的にもDASDネックは起きにくいと判断しています。
図2 オンライン業務の稼動状況
図2はオンライン業務の稼動状況を一目でわかるようにした図です。赤くて（最大処理時間が30秒以上）大きい円（稼働率が高い）があると問題です。図の中央に円が4つ重なっていますが、平均処理時間（横軸）も0.2秒程度で大きな問題はなさそうです。見えにくいのですが、右下には赤い円が1つ、ピンクの円が2つあります。
この他にバッファの使用状況やボトルネックなどのチェックをかけます。
以上のようにシステムを客観的に見ると、小さな問題はいくつかありますが大きなボトルネックは見当たらず、平均点以上にきれいに動いていると判断しました。
この結果をふまえて、チューニングの経緯や性能評価報告書に目を通します。お客様やSEがどんな価値観を大切にして改善に取り組んできたのかをイメージします。
１．３ 問題と仮説構築
最初に一般論をお話しします。問題とは目標と現実とのギャップであり、性能上の代表的な問題は「遅い」ことです。（「速い」ことも問題となります。）「遅い」には以下のようなケースが考えられます。
①性能目標値と比べて遅い ･･･ 【現在－目標値】目標値があることが稀
②目標値はないが初めから遅すぎる ･･･ 【現在－常識】今からでも目標を設定する
③前より遅くなった ･･･ 【現在－前】前のデータが残っていることはほとんどない
④遅いときがある ･･･ 【遅いとき－普通のとき】今から測定できる
⑤Aと比べてBが遅い ･･･ 【B－A】今から測定できるかもしれない
一番多く最もやっかいなケースが前のデータが存在しない③です。そんなときは慌てず騒がず、まず5W1Hで整理しましょう。
私が経験したHowの最短は、ダム端末で入力しているオペレータの方のタイミングが一瞬ずれるという0.1秒以下のものでした。これは非常にむずかしい問題です。
10分だった処理が20分くらい遅くなってくれれば、現在を適切に分析することで問題を想像することができるかもしれません。
次に、前と現在との環境変化を整理する必要があります（表1）。メーカにとって一番困るのはCPUを移行して遅くなるケースでしょう（でした）。CPUの特性上、本当に遅くなることもあり得ますから、どんな手段を使っても性能を改善するしかありません。
表1 環境の変化の例
さて、現場に戻します。今回、お客様からの指摘事項は3件で各々仮説をたてました。
売上が1.5倍になってもシステムは安定稼動できるか
仮説：図1からCPU、メモリは問題ない。業務アプリの処理能力向上が課題。
通常１秒かからない受注、売上処理のレスポンスが、集配信処理が動くと数秒になる
仮説：原因はデータベースの排他待ちだろうが、原因の特定が最初の課題。
仮説：お客様自身がデータベースの性能設計を理解することが課題。
環境の変化ですが、最近のGSでは珍しい業務量の増加です。 この段階で本案件は単純なシステムチューングでは解決せず、業務アプリやデータベース設計に首を突っ込む覚悟が必要と判断しています。
この状況でチューニングに過大な期待をすることは危険であり、今後の性能改善についてお客様に次のようにお伝えしました。
今までの「数秒～10秒の改善」から今後は一桁小さい「１秒の改善」が要求されています。この性能改善を効果的かつ効率的に実施するには「もぐら叩きの対応」、「経験と勘による対応」から脱却しなければなりません。即ち、網羅的かつ詳細なデータ解析を行い、根本原因を追究し、戦略的に対策を打つことが重要です。つきましては、性能評価プロセスに沿って作業を進めることをご提案します。
次回は、A社での事例（2）～自信を持たせる を紹介します。
以 上
コメント
投稿にはログインしてください