12.2.情報のタイプと源泉（１）：Quantitative System Performance
12.2. 情報のタイプと源泉
既存システムの待ち行列ネットワーク・モデルのパラメータ値を指定するために必要な情報には、システム構成に関する静的な情報と、さまざまなモニタリング・パッケージによってシステム稼働中に生成される記録から抽出される動的な情報が含まれる。若干の情報はアカウンティングの目的で記録されるが、その他の情報は明示的に性能評価の目的で記録される。洗練の程度がさまざまであるソフトウェア・パッケージはシステム稼働中に記録された情報を蓄積し、解析し、報告するために利用可能である。このセクションでは必要な情報について、それをどうしたら得ることが出来るかについて、そしてどのようにそれを管理することが出来るかについて、手短に検討する。我々の意図は包括的であることではなく、むしろ、待ち行列ネットワーク・モデルの構築と仕様に特に関係する点を強調することである。
要求される情報のタイプの１つはシステムのハードウェアとソフトウェアの記述である。ハードウェアに関しては、この情報はシステムの構成要素の列挙（プロセッサ、チャネル、保管デバイス、通信デバイス、など）とそれらの間の接続の表示（例えば、特定の保管デバイスからメモリへそれを通してデータが移動することが可能なパス）を含む。ソフトウェアに関しては、この情報は使用するＯＳとリソース配置に影響を与えるパラメータの値を含む。そのようなパラメータの例はさまざまな作業負荷要素についてＣＰＵスケジューリングの優先度や保管デバイス上でのファイルの配置、などを含む。
このシステム記述は比較的静的であって、それは週毎にあるいは月毎にのみ変化する。それがハードウェアについて提供する情報はどのリソースがモデル内でセンターとして表現されるべきであるかを示唆する。それがソフトウェアと運用方針に関して提供する情報は適切なモデル化仮定を示唆し、測定データの解釈に役立つ。
要求される別のタイプの情報はさまざまなモニタによってシステム稼働中に動的に記録される。アカウンティング・モニタはバッチ・ジョブや会話セッションの終了時に、ジョブやセッションによって消費されたシステムリソース（ＣＰＵ秒やＩ／Ｏ動作やメモリ滞在時間や接続時間など）を示す記録を書く。ソフトウェア性能モニタは他の観点からリソース使用量と性能状態を記述する記録を書く。指定された期間で、待ち行列長やデバイス状態の指標はサンプルが採られ結果が記録に書かれる。また、意味があると考えられる若干のイベント（主メモリからの客のスワピングのような）が記録に残されるだろう。
その量と記号化のため、アカウンティングとソフトウェアのモニタが生成する記録は直接には使用可能ではない。むしろ、それらは特定目的（例えば、アカウンティング、作業負荷予測、性能モデル化）用にサマリ情報を生成する報告ルーチンによって処理されなければならない。大部分のアカウンティングとソフトウェアのモニタは記録コンポーネントと報告コンポーネントの両方を含むパッケージである。例えばアカウンティング記録は処理される作業の個々の単位について書かれ、アカウンティング・プログラムは個々のアカウントへの課金を決定するために最近のアカウンティング記録を周期的に処理するだろう。同様に、ソフトウェア・モニタは若干のイベントで、あるいはサンプリング間隔で記録を書き、ポストプロセッサはあとでその記録を分析し、システムのチューニングと性能評価に役立つように組織された報告を生成する。
アカウンティングとソフトウェアのモニタが生成するレポートは通常、２つの仕方の１つで編成されている。若干のレポートはクラス・ベースである。それらはユーザ毎、あるいは作業負荷要素毎に情報を組織化している。他のレポートはリソース・ベースである。それらは情報をシステム・リソース毎に組織化している。リソース使用量を作業負荷要素とリソースの両方毎に確実にブレークダウンするモニタは大部分のシステムでは普通に使用されない。（存在するそれらは法外に高いモニタリング・オーバヘッドを引き起こす。） セクション１２．３から１２．５で記述されるように、パラメータ値決定の際の作業の多くは、普通に使用可能な測定情報の不適切さを克服する必要から発生している。ソフトウェア・モニタが改善されるにつれて、パラメータ値決定の仕事はより煩わしさの少ないものになり、この章で記述する技法の若干は不要になるだろう。
情報を得るために報告ルーチンを用いる時、情報を収集する期間を特定する必要がある。一般に、ピーク負荷は最も顕著な性能問題を示すのでピーク負荷の間モニタを実行することが適切である。観測期間は終端効果が測定の精度にあまり影響を与えないのに充分なくらい長くあるべきである。終端効果は、若干の客が一部は観測期間の中で一部は外で処理されているということによって引き起こされる測定誤差である。特に、システムは測定期間に渡ってフロー・バランスで稼動するのでジョブの到着レートと完了レートは等しい、と仮定するのが普通である。しかし、若干のジョブは期間中に到着するが完了せず、他のジョブは期間前に到着するが期間中に完了するため、フロー・バランスは成り立たないかもしれない。明らかに、より長い観測期間から得られた測定はより短い期間よりこれらの終端効果による影響が少ない。通常、３０分から９０分の観測期間がソフトウェア・モニタ・データを得るのに適切である。もしモニタリング・オーバヘッドが心配であるならば、より短い期間を使用出来るが、例外の危険性は増加する。
役立つ情報の他の源泉はハードウェア・モニタと（データベースや通信サブシステムのような）特定アプリケーション・サブシステムに特化したモニタを含む。ハードウェア・モニタは、システムの「外部の観測者」であるので、正確な測定データを得、システム稼動を動揺させない。しかし、それらはリソース使用量と作業負荷要素に関係付けることが出来ない。特化したアプリケーション・サブシステム・モニタは、標準モニタがその活動を記録することをホストＯＳからの自立していることが妨げているようなサブシステムの性能を評価するのに役立つ。（例えば、ＩＢＭのＲＭＦは個々のＩＭＳデータベース・システムのトランザクションについての情報を記録しないので、ＩＭＳのために特殊なモニタが必要である。） ハードウェア・モニタと特殊アプリケーション・サブシステム・モニタから利用可能な任意の情報は利用されなければならないが、この章での我々の議論は大部分の中規模あるいは大規模コンピュータ実装で普通に報告される情報の種類に制限することにしよう。
「12.2.情報のタイプと源泉（２）」に続きます。
