課題：　メインフレームのオンラインレスポンスを改善する

本気で、メインフレームのオンラインレスポンスを改善したいお客様へ

PDL(Performance Data Logger) だけでは、レスポンス悪化の原因はわかりません。
オンライン処理の性能を改善するポイントは何なのか、その秘密を明かします。

性能問題への対応の第一歩は、性能データPDL(Performance Data Logger)の解析から始まります。これは基本中の基本です。
PDLの解析は、オンラインレスポンス悪化の事実をデータ（数字）として確認することが主たる目的です。
レスポンスが悪化した表面上の原因がわかることはありますが、根本原因がわかることはほとんどありません。

つまり、「PDLを調査中」というアクションでは、本質的な改善策は期待できないのです。
そもそもPDLの調査は1～2日あればできますから、それ以上に時間がかかるということは何もやっていないのかもしれません。（丸投してるだけ？）

さて、上記を前提知識として問題です。　ケース１と２、どちらの原因調査及び性能改善の方がむずかしいと思いますか？

　ケース１．　普段は1秒のレスポンスが、60秒になってしまった。（＋59秒）
　ケース２．　普段は0.1秒のレスポンスが、0.3秒になってしまった。（＋0.2秒）

答え、　普通はケース２の方が圧倒的に難しいです。事例を使って説明します。

事例１（ケース１）　CPU： GS8800　　OS： MSP　　改善目標：最大レスポンスを現行に1/５（80%短縮）にする
　

　　成果：最大レスポンスは約1/10（90%短縮）になった

　PDLからわかること
　　・プログラム(SMQN00,SMQN01,SMQN02)の処理時間(Message Process Time)が40～50秒である。
　　・NDBまたはAIM/VSAMで数10秒の排他待ちが発生している。データベースがSymfoWAREならわからない。

　改善のポイントと調査方法
　　① データベースの排他待ちを削減する
　　　　・PDLからNDB、AIM/VSAMで排他待ちが発生しているか確認する。
　　　　・SMFから長時間の排他待ちの発生状況を確認する。
　　　　・AIM課金統計情報から通常時のレスポンス、悪化時のレスポンスを把握する。また、悪化時の他プログラムの悪化状況も確認する。
　　　　・データベース環境定義を確認する。
　　　　・SMFとAIM課金統計情報から、排他待ち発生ロジックの仮説を立てる。
　　　　　　※長時間の排他待ちは外から見えやすい、即ち原因は見つけやすいのです。１分の排他待ちのウラには１分も占有しているタスクが存在しています。
　　　　・改善方法の立案。データベースのアクセスモードの改善、排他占有時間の短縮　等
　　② CPU時間、CPU待ち時間を削減する
　　　　・AIM課金統計情報からトランザクションのCPU時間を把握する。
　　　　・CPU/IO頻度分析（弊社が開発したCPUとI/O発行の特性分析手法）
　　　　　　※これができないから、「枝葉を見て森を見ない」、即ち役に立たない改善をしようとするのです。
　　　　・GTFトレースの調査とプログラムロジックの確認
　　　　・改善方法の立案。無駄な処理の削減、CPUの優先度を上げる。　（AIMの排他制御ロジックの無駄を発見！）
　　③ I/O時間を削減する
　　　　・AIM課金統計情報からトランザクションのI/O回数を把握する。
　　　　・GTFトレースの調査とプログラムロジックの確認
　　　　・改善方法の立案。無駄なI/Oの削減。

事例２（ケース２）　CPU： GS8900　　OS： XSP　　改善目標：最大レスポンスを現行に1秒以内にする
　

　　成果：最大レスポンスは１秒以内に、平均レスポンスも半減した。

　PDLからわかること
　　・プログラム(SMQN A,SMQN B,SMQN C)の最大処理時間(Message Process Time)が10～20秒である。

　改善までのプロセス
　　① PDLから状況把握をする
　　　　・平均レスポンスは速く(0.1秒以下)、かつレスポンス悪化するのは1日数回であった。
　　　　・データベースの排他待ちは発生していない。
　　② STF0トレースを採取し原因を調査する
　　　　・AIM SNAPを取得していることが判明。
　　　　　　※常識的に考えられないことを見つけるには、事実を追いかけるしかありません。架空の話しを延々とするのは時間の無駄です。
　　③お客様へのヒアリング
　　　　・「運用中にAIM SNAPを採取するなんてことは当然してません。」
　　　　・MLOGを調べたところ、システム起動時に取得開始していることが判明。（お客様は全く認識していなかった）

　これが、私たちのオンライン処理の性能改善です。

　いかがでしょうか？　　２つの事例ともPDLの調査だけでは原因究明には至りません。
　私たち独自の性能改善のポイントを公開します。

　１．トレース（GTF、STF0）の解析を早い時期に行い、原因究明に向かって一直線に突き進む。

　２．弊社で開発したCPU/IO頻度分析を行い、システム全体を俯瞰（ふかん）しながら、システムの特異性を発見する。

　３．ロジカルでない動作は、OS、AIMからユーザプログラムまで踏込んで調査する。
　
　
　
　お客様のメリット
　　・アクションが速い
　　　　（オール富士通って言葉は立派ですが、メーカ内部の調整にばかり時間がかかって実際はたまりません。）
　　・現場重視
　　　　（偉くなると適当な言い訳をして現場に行きたがらない。）
　　・本当に問題が解決する
　　　　（登場人物が多いと責任の所在が不明確になるだけ。結局誰が解決してくれるの？）
　　・改善後にお客様が運用できる
　　　　（やりっぱなし、結果オーライ主義はもうコリゴリ。）
　
　
　
　担当SEさんのメリット
　　・自分の手に負えない性能トラブル調査から解放される
　　・本来のあなたが力を発揮すべき仕事に注力できる
　　・この機会においしいノウハウだけをつまみぐいすることも可能
　
　
　
　
　３年前のチューニングの常識は通用しない
　
　私は、富士通のユーザ団体である「富士通ファミリ会」の論文で提言しました。
　　　タイトル：　「性能管理・改善のブレークスルー　－自らの常識を破り、どのように性能改善を実現したか－｣
　
　さらに、GS21 600 と GS21 200 ではチューニングの手法は異なります。　（OSの違いだけではありません）
　これを意識しないで性能改善をやったら大変なことになります。
　

　「オンラインレスポンスが悪くてエンドユーザからクレームが出ている。」
　「ホストをレベルアップしたのにレスポンスが悪くなった。」
　「性能の小さい機種にリプレースするけど、オンライン性能は落としたくない。」
　
　　そんなお客様へのお手伝いをします。
　

　性能改善コンサルティング

　
　
　まずはご相談ください（無料）。解決できそうな問題なのか、ハード増強が必要なのか、すぐに判断します。　
　　　　　　　　　　↓↓↓

今すぐ問い合わせる

2006年1月作成、2007年1月修正
株式会社アイビスインターナショナル
代表取締役　有賀　光浩

株式会社アイビスインターナショナル　134-0003 東京都江戸川区春江町4-17-12

課題： メインフレームのオンラインレスポンスを改善する

課題：　メインフレームのオンラインレスポンスを改善する