|
| 本 文 | 有賀のコメント（2006年3月） 有賀のコメント（2011年10月） |
||||||||||||||||||
| １．はじめに 平成3年度より「システム性能評価サービス」を開始し、平成4年6月までに24件のサービスを実施した。18件は性能問題対応であり、中でも12件はAIM関連の問題であった。 システムの性能問題対応をする際、迅速にかつ正確に問題解決することを要求される。業務や環境の知識が全くない状況下で、我々が工夫し実践しているAIMシステムの性能評価方法について論ずる。 AIMシステムの性能問題は、DB構造やプログラムの見直しとなることが多い。そのため、早い時期に問題を見つけ対処することが重要である。 |
・AIMシステム→DB/DCを使っているシステムの意。 ・SymfoWARE(RDBⅡ)の登場は1993年(平成5年)である。 ・CPU/IO頻度分析と仮説検証型性能解析手法の開発（2006年）により、迅速かつ効果的なプログラムチューニングを実現した。 |
||||||||||||||||||
| ２．性能評価の現状 2.1 性能評価とは 本稿では性能評価を次のように定義する。 「性能データを採取し現状分析を行う。問題点については原因分析、対策立案、効果予測を行う」 必要であれば性能評価の次工程でチューニングを実施し、再度性能評価を行う。 精度の高い性能評価を行うためには、まず状況に応じた適切なデータを正しく採取しなければならない。そのため、各データごとに「データ採取手引書」を作成し提供している。性能評価で活用する性能データを表1に示す。 |
・現在でも定義に違和感はないし、課題は現在でも課題である。 ・性能評価プロセスの標準化（現在はV3.1）を提案している。 ・さらに質の高い性能評価を行うためには、一つの性能データを信用してはいけない。 |
||||||||||||||||||
表1 使用頻度の高い性能データ一覧
|
・*1 誤植があったので修正。 ・AIMモニタ情報はほとんど知られていないが、NDBへの発行マクロやその回数がわかるので便利。 ・性能データは現在でも表1にSymfoWAREが追加されただけ。 ・性能データとしての一貫性がなく、使える編集ツールを標準提供しなかったことが14年後まで尾を引いている。 ・SMFEDIT、PTRAP、TRAP/IOはSEツールである。 【用語】 ・AIM配下：AIMの管理下でジョブを動かすこと。オンラインはAIM/DCを使うので全てAIM配下。バッチはAIM/NDB,AIM/VSAMやSymfoWARE等を使うときはAIM配下。 |
|
| 本 文 | 有賀のコメント（2006年3月） 有賀のコメント（2011年10月） |
|||||||||
| 2.2 有効に利用されていない性能データ しかし、ほとんどのユーザはPDLしか使っておらず、性能データは有効に活用されていない。原因として次のことが考えられる。 ・性能データの種類が多く、いつどのデータを採取したらよいのかわからない ・採取しても分析の仕方がわからない この問題は、本稿で論ずる性能評価手法を明確にすれば解決できると考える。性能データは、編集ツールを使って可視化される。従って、編集ツールは情報を正確にかつわかりやすく出力する重要な位置づけを持っている。 |
・14年後の今はPDLの採取もできなくなった。 （残念ながら19年後も変わるはずがない。） ・基本的な分析の仕方は変わっていないが、数字の読み方は常に変化している。10年前に設定した「指標値」と比較しているのは無意味というより、重大な判断ミスを犯す危険がある。 ⇒ 性能指標値21 ・ＧＳメタボ診断では、CPUやメモリ等のリソースの無駄に言及している。 |
|||||||||
| 2.3 編集ツールの問題点 (1) 平均値の精度が悪化する 各ツールでは、平均値と最大値が出力されることが多い。平均値を扱う際、データの丸め込みが発生するため注意が必要である。 レスポンス時間を例にとると、図1のような分布になることが多い。 「終了」や「確認」などのレスポンスの速いトランザクション（左の山）が、評価したい処理（右の山）の平均値をさげてしまうことがある。 |
・数字を扱う上での基本。 |
|||||||||
|
||||||||||
| (2) 要件を絞り込めず効率が悪い 例えば、「排他待ちの発生しているデータベースのみ出力する」といった要件を絞り込む機能がない。 |
・MSPで0件SMQNを表示しない機能を提供したのは、2000年以降である。 | |||||||||
| (3) 出力リストが見にくく効率が悪い ・出力リストに無駄があり枚数が非常に多い ・欲しい情報が分散している |
・CSV出力すべきである。 ・今からでも、PDLやSMFのログをそのままCSV出力する機能を作って頂きたい。 |
|
| 本 文 | 有賀のコメント（2006年3月） | |||||||||||||||
| 2.4 補完ツールによる問題解決 性能評価ツールを洗い出した結果、前節(2)(3)を解決するツールはいくつか提供されていた。 更に、(1)についてはデータ精度の向上、(2)はデータの局所化、(3)は出力データの集約化に重点をおき補完ツールを作成した（表2参照）。 なお、(1)については、平均値でなく1トランザクションごとの実データを使用できるようにして対応した。 これらのツールにより性能評価作業を正確にかつ効率よく行える基礎ができ、実際に運用できる段階となった。 |
・システムの数だけ補完ツールが作られていた。新人の勉強材料という側面もあったが、その程度の品質のため、他システムに流用できるものは少なかった。 | |||||||||||||||
表2 補完ツール一覧
|
・PDLの補完ツールは、INPUTをPDAのリストでなくPDLログデータを直接さわりたくなっていく。（今も） ・SMFの編集ツールは本来システムで提供すべきである。（今も） ・JXFACCTGユーティリティでの出力機能はあまりにもお粗末である。（今も） |
|||||||||||||||
| ３．AIMシステムの性能評価手法の確立 3.1 手法確率の背景 実施した性能問題対応のうち、67%はAIMシステム上で発生している。オンラインレスポンスの悪化は、直接業務に影響が出るため大問題となることが多い。 PDLを使ったハード資源(CPU、メモリなど）の性能評価手法はよく知られている。しかし、AIMシステムの評価は、ユーザの業務、DB環境、システム環境等についての知識が必要であり非常に困難と言われている。業務や環境の知識のないAIMシステムを、迅速かつ正確に評価する手法が必要となった。 |
・今でも70%がデータベース関係、残りがユーティリティ、サブシステム、ハード関係か。 ・プログラムの質は著しく低下している。 ・自治体向け一部製品は、AIMの基本仕様通りに作られていないため性能品質が悪い。対処方法はオープンサーバ上で動かすしかない。 |
|
| 本 文 | 有賀のコメント（2006年3月） 有賀のコメント（2011年10月） |
||||||||||
| 3.2 性能評価モデルの構築 作業を標準化するため、調査ポイントを次の2点にしぼった。 (1) AIM資源に待ちが発生していないか ・バッファ不足による待ち ・タスク待ち ・排他待ち (2) 無駄な動きをしていないか ・途中実更新は発生していないか ・プログラムに無駄なロジックがないか ・無駄なI/Oを発行していないか これらを基に図2に示すAIMシステムの性能評価モデルを構築した。 |
・「性能評価モデル」というより「性能評価プロセス」 （現在はV3.1） ・ハード性能の向上により(1)による影響は少なくなってきたが、(2)が問題となってきている。 ・SQLを使うようになり、排他待ちや処理の無駄は倍増している。 |
||||||||||
|
①～⑥は性能評価作業の流れを示している。 ①PDL、SMFを採取する。 ②補完ツールを使用しデータを分析する。 ③ADLの定義を見直す。改善策とその効果予測をたてる。 ④問題プログラム診断のためのデータ採取支持をする。 ⑤④で指示されたデータを採取する。 ⑥プログラムごとに問題点整理と改善策を検討する。 |
||||||||||
| ４．AIMシステムの性能評価手法 図3の項目を調査することによりAIMシステムの性能評価を実施する。
|
・今ではSymfoWAREに関する調査が必要。 【用語】 ・MQN：Message Queue Node オンラインプログラムの入り口。複数のSMQN(Secondariy MQN；1本のプログラム)を束ねている。 ・HLF：更新後ログを格納するファイル。一緒にAIM課金統計情報やユーザ課金データも蓄積する。 ・BOF：更新前ログを格納するファイル。途中実更新が発生したとき、またはBOFバッファが不足したときに書き出す。 ・XIF：NDBの拡張インデックスファイルのこと。 |
||||||||||
|
| 本 文 | 有賀のコメント（2006年3月） 有賀のコメント（2011年10月） |
|||||||||
| 4.1 性能データの採取 (1) 作業項目 ・PDL (R, Xレポート）を採取する。 ［プログラムを個別に調査するとき］ ・AIM課金統計情報、AIMモニタ情報、STF0（I/Oトレース）を採取する。 (2) 注意事項 a) オーバヘッドの考慮 性能データを採取するとシステムにオーバヘッドがかかる。そのため、利用者はいつどのデータを採取するか十分理解する必要がある。特に次の2点は重要である。 ●AIM課金統計情報 データをHLFに書き込むため、HLFボリュームの負荷増加とHLFバッファの枯渇が発生することがある。HLFの切り替わりも早くなる。1トランザクションのレコード長は以下の通り。 AIM課金：約200バイト、 AIMモニタ：約260+156*DMLマクロ命令 バイト ●STF0トレース データ量が多いため事象と時間を絞り必ずMTに採取する。DASD上だとログファイルを巡回しようするためデータ損失が発生することがある。 b) データロストの防止 採取したデータにロストがあると、精度が極端に悪化する。PDLとSTF0は起動時に必ずバッファ個数を指定する。（PSQAに確保される） c) データ採取のタイミング 被測定ジョブ（評価したいジョブ・業務）と各測定データを採取する契機を図4に示す。 |
・DASD容量が増えたので、トレースはDASDに数100CYLアロケートして採取することが多くなった。 ・XSPのPDLのバッファはV03061からEPSQAに改善された。 |
|||||||||
|
・今も変わっていない。 | |||||||||
| 4.2 現状分析と問題分析 採取したデータを用い以下の調査を行う。 (1) 調査項目 a) バッファ不足が発生していないか（PDL,SMF） ・原因：バッファが小さい（ADL定義ミス） ・対策：バッファサイズの拡張、バッファ個数の増加 b) 途中実更新が発生していないか（SMF） ・原因：ページバッファ（XIFバッファ、データセットバッファ）が不足している。 ・対策：バッファサイズの拡張（ADL定義ミス？） c) MQNでタスク待ちが発生していないか（PDL) ・原因：マルチタスク化していない。タスク多重度が小さい。処理時間の長いプログラムがある。 ・対処：最適なタスク多重度の設定。 d) 排他待ち、デッドロックが発生していないか（PDL、SMF） ・要調査：プログラムのアクセスモード、シーケンス、DB構造をチェックする。 e) 処理時間の長いSMQNがないか（PDL） ・要調査：MQN内の処理時間にバタツキがないかチェックする。 (2) 注意事項 a) バッファの拡張 仮想記憶の圧迫に注意すること。 HLFバッファ、DCMSバッファ ⇒ EPSQA上に確保 BOFバッファ、タスクログバッファ ⇒ EREGIONに確保 b) タスク多重度の増加 ハード資源の使用状況の把握、タスク間で資源(DBなど)を競合しないか確認する。 |
・今も変わっていない。 【用語】 ページバッファ：NDBをアクセスする際の中間バッファ。PEDでサイズを定義する。 ・1999年頃に私が富士通で立ち上げた性能点検サービスで、この辺のチェックを重点的に行った。 ・ＧＳメタボ診断でももちろん対応している。 |
|||||||||
| 4.3 ADL定義の見直し (1) 調査項目 a) PEDコマンドの見直し ・SWAP POINT、各種バッファ、アクセスモード、排他占有単位、タスク多重度をチェックする。 b) MQNコマンドの見直し ・PROCESSING TASK LIMIT句をチェックする。 ・SMQNのくくり方をチェックする。 (2) 注意事項 ADL定義の省略値は、性能面ではよくない値が多いので注意が必要である。効率よくかつ正確に行うため、現在ADL定義のチェックツールを作成している。 |
・今も変わっていない。 ・SymfoWAREをアクセスする際、PEDにスキーマ名を切らなくても（間違えても）アクセスできるため、整合性をチェックするのが難しくなった。 【用語】 ・PED：AIM配下のプログラムの環境を定義するファイル。ジョブ実行時に使用するPEDをJCLで指定する。PEDの内容は事前にDDMSでAIMディレクトリに登録しておく。 |
|
| 本 文 | 有賀のコメント（2006年3月） 有賀のコメント（2011年10月） |
||||||||||||||||||||
| 4.4 問題プログラム診断 今までの分析において、問題のありそうなプログラムに対してはプログラムの診断を実施する。 (1) AIM課金・AIMモニタの補完ツール 図5（省略）はAIM課金統計情報とAIMモニタ情報の補完ツールの出力例である。AIM課金統計情報は1トランザクションごとに処理時間等が出力される。また、AIMモニタ情報はDBの1DMLマクロごとに情報が出力される。このように、従来できなかったトランザクション単位の性能評価を可能とした。 (2) AIM課金の調査項目 図5（省略）を基に調査項目を説明する。 ①処理時間とCPU時間＋I/O時間に大差がないか ⇒ 目安：I/O時間＝IO-CNT * 3ms (*2) 大差があるときは、ボトルネック調査のための詳細分析が必要。 注）IO-CNTはAIM配下のファイルのみ ②途中実更新が発生していないか ③ファイルへのアクセス回数は妥当な数字か ④アクセス回数に対し実I/O回数は妥当か ⇒ ページサイズ、バッファ数は妥当か (3) AIMモニタ情報の調査項目 ①排他待ちが発生していないか どのジョブがどのレコードで競合し合うのか把握する。例（省略）では"GET ANY R001" で400msの排他待ちになっている。 ②DBのアクセスシーケンスは正当か ③DMLマクロ発行時のI/O回数、処理時間は妥当か 【事例】 共通サブルーチンでDBアクセスしているが、パラメタミスで無駄なアクセスをしていることが判明。プログラム修正によりレスポンス改善した。 (4) I/Oトレースの調査項目 ①システム全体でI/Oの多いファイルがないか ②ジョブ内で無駄なI/Oを発行していないか 【事例】 AIM配下外でVSAMを使用し、トランザクションごとにオープン処理をしていたことが判明。プレオープンしレスポンスが約4秒改善されてた。 【補足説明】 従来、ジョブ名と空間識別子(ASID)の対応付けができないため、TRAP/IOのバッチジョブ名指定はできなかった。今回、バッチジョブごとのASIDを出力する補完ツールを作成し、［ASID + 時間］指定で分析可能となった。 |
・*2 原本は30msだったが3msに変更した。 ・AIMモニタはHLFへの出力件数が多いため、実際は10年近く使っていない。しかし、テスト機での検証では有効だと考える。 ・(4)に示す事例は、2006年2月のM市役所でほとんど同じく再現した。 ・仮説検証型性能解析ではSTF0(GTF)トレースの解析を積極的に行っている。 |
||||||||||||||||||||
| 図5 補完ツール出力例 省略 | |||||||||||||||||||||
| 4.5 総合評価 (1) 評価方法 各フェーズの分析内容は表3のような一覧表にまとめ、詳細は1件1葉で補足説明する。問題点に対し複数の改善策があげられるが、ユーザ環境を考慮して各々の工数と効果について検討する。 効果は、現状の待ち時間や無駄なI/O回数からある程度予測できる。しかし、正確な値を出すのは難しいため、大小表現で評価することが望ましい。 (2) 注意事項 1つのボトルネックが解消されると、次に他の資源（例えばCPU）が過負荷になることがある。効果はトータル的に検討しなければならず注意が必要である。 |
・メーンフレーム（当時Mシリーズ）性能評価をやり始めて1年程度であり、この程度の評価でご勘弁願いたい。 ・今は、効果は何らかの形で数字化している。 ・性能評価はシステム資源とユーザ資源の両輪で行うことが重要である。ユーザアプリの性能品質を可視化したCPU/IO頻度分析が効果的である。 |
||||||||||||||||||||
表3 性能評価作業のまとめ方
|
・現在では、VBLDLはVDFに変わった。 ・DISKの性能向上により、ISP機能は使わなくなった。 ・カタログは今でも問題である。 |
||||||||||||||||||||
| ５．事例紹介 対応したユーザの中から、オンライン性能が大幅に改善した事例を紹介する。 【現象】 単体で2～3秒のレスポンスが、運用中数10秒になることがある。CPU、メモリには余裕があった。 【調査結果】 ●AIMシステム全体の評価 ①タスク待ちが発生している (PDL) ②途中実更新が発生している (SMF) ③排他待ちが発生しているDBあり (PDL) ④MQNコマンド見直し ●問題プログラムの診断 当初ユーザは、設計上オンラインで排他待ちは発生しないと言っていた。AIMモニタ情報を調査した結果、バッチジョブが実行されていて排他をかけていたことが判明した。 【結果】 チューニングとバッチ処理の運用制限にて、ほぼ単体レスポンス（約3秒）まで改善した。 |
・今でも最も多いケースである。 ・今では、プログラムの作りが悪いが一番か。 |
||||||||||||||||||||
| ６．今後の課題 本論文内容をはじめ、性能評価に関するノウハウをSEにフィードバックする。また、サービスを年会に開始する予定であり、ノウハウを有効に活用していきたい。 ７．参考文献 省略 |
・素直に反省しましょう。 |
| 2006年4月作成、2011年10月修正 株式会社アイビスインターナショナル 代表取締役 有賀 光浩 |
 株式会社 アイビスインターナショナル 134-0003 東京都江戸川区春江町4-17-12 |
| All rights reserved, Copyright (c) IBIS International Inc. 2005-2015 |
