6.3.2.修正解析のあるモデル：Quantitative System Performance

「6.3.1.会話型システムのモデル」の続きです。（目次はこちら）

6.3.2.修正解析のあるモデル

　このケーススタディでは、提案されたいくつかのハードウェアとソフトウェアの構成への変更の利点を評価するために単一クラス・モデルが使用された。考慮下にあるシステムは３つのチャネルを持つIBM System/360 Model 65Jであった。チャネル１と２はそれぞれ８台と１１台のIBM 2314-テクノロジー・ディスクを接続されていた。チャネル３はドラムと接続され、それはＯＳによって排他的に使用されていた。このドラムの使用はユーザ・ジョブの処理と完全にオーバラップしたので、モデルから省略された。（モデル内の客はユーザ・ジョブを表し、それはけっしてドラムを訪問しなかった。）
　このシステムのモデルを図６．３に示す。それはＣＰＵやディスクやチャネルの処理要求時間や、作業負荷タイプや負荷強度を指定することによってパラメータ値を決定される。モデルはチャネルを表すサービスセンターを含んでいるので我々の「標準」モデル（セクション４．５参照）と異なっている。一般にこの種のモデルは（これから短く説明するように）かなりの誤差をもたらす可能性がある。しかし、このシステムの特徴のために、よい精度が得られた。

図６．３　システム・モデル

　１ジョブあたりのベースＣＰＵ処理要求時間は測定期間における総ＣＰＵビジー時間（システムとユーザの両方の時間）をその期間に完了したジョブ数で割ることで見積られた。よって（ＣＰＵスケジューリングやユーザＩ／Ｏを処理するのに必要なオーバヘッドのような）システムＣＰＵオーバヘッドは全てのジョブに等しく割り付けられた。
　Ｉ／Ｏサブシステム（ディスクとチャネル）のパラメータ値を決定することはより複雑であった。システムのディスク・テクノロジーは各々のディスクでシークはそのチャネルと独立に開始できるが、ディスクとチャネルの両方が回転レイテンシー（データがディスクのリード／ライト・ヘッドに向けて回転している期間）とデータ転送の間、保持されることを要求した。モデルでは、チャネル処理要求時間はレイテンシーとデータ転送の平均時間の和が設定され、ディスク処理要求時間には平均シーク時間がセットされた。よって、Ｉ／Ｏ処理時間の全ての要素は正確に１回、表現された。（もし処理の３つの要素全てがディスクで表現されたならば、モデル内の客はレイテンシーと転送の処理を２回経験し、予測性能尺度は深刻に間違うだろう。）
　複数コンポーネントＩ／Ｏサブシステムをこのようなし方で表現することには危険がある。実際のシステムとは違って、モデル内の客はディスクとチャネルの両方をけっして同時に保持しない。よって、論理的にあるジョブのレイテンシーと転送の部分のために使用されているディスク・センターは同時に他のジョブによってシークのために使用されることが可能なので、モデルには不自然な並列性の可能性が存在する。この不正確さを考慮することは一般には難しい問題である。（第１０章はＩ／Ｏモデル化についてより詳細に検討する。）　しかし、この特殊なシステムの場合、ディスク・デバイスの稼動率がかなりよくバランスがとられており、また、ディスク総数が平均多重プログラミング・レベルよりずっと大きかったのでモデル内の潜在的並行性の効果は無視してよかった。よって、客が他の客によってすでに使用されているディスクから処理を要求する確率は小さく、その結果、不自然な並列性の量も小さい。
　システムの測定は、平均多重プログラミング・レベルが測定期間中にかなり変化したことを示していた。この変動を考慮するために、モデルは観測された多重プログラミング・レベルのそれぞれについて１つずつ評価された。性能予測は個別の解をシステム内で観測された対応する多重プログラミング・レベルの割合で重み付けして得られた。
　モデル化スタディの目的は提案されたシステムへの以下の変更の効果を評価することであった。

１のチャネル上の８台の2314テクノロジー・ディスクを６台のIBM 3330ディスクで置き換える。この変更の効果は、影響するチャネルとディスクのサービスセンターの処理要求時間を変えることでモデルに反映された。というのは3330のシークと転送データは2314よりも速く、また回転位置感知（RPS: rotational position sensing）機能を持っているからである。この機能は回転レイテンシーの間ディスクがチャネルから切断され、要求されたセクタがリード／ライト・ヘッドの下にまさに来ようとしている時のみ再接続することを可能にする。

拡張コア・ストレージ(ECS: extended core storage)をより速いメモリに置き換える。ＣＰＵの処理レートがメモリ・アクセス時間によって制限されていたのでこれは事実上ＣＰＵ速度をより速くするだろう。ECSの外で実行されるプログラムの大部分はシステム・ルーチンだったので、この変更の影響は、スーパバイザ・ステート（システム）処理に対応するＣＰＵ処理要求時間の部分の削減によってモデルに反映された。

ＯＳの改善を実装する。この改善はオーバヘッドを８％削減すると予想された。よってこの変更はＯＳ処理に対応するＣＰＵ処理要求時間の部分の減少によってモデルに反映された。

　提案されたシステム改善のさまざまな組合せを反映するようにモデルはそのパラメータ値を決定され、ユーザ（問題状態）ＣＰＵ稼動率への影響が書き留められた。（性能尺度として $U_{CPU}$ を使用することはこのスタディの奇妙な側面である。というのは $U_{CPU}$ は単にプロセッサを遅くするだけで増加させることが出来るからである。より普通な尺度はシステム・スループットとシステム応答時間である。）　ＯＳ改善だけで $U_{CPU}$ の５％増加をもたらすと予測された。ＥＣＳ置き換えとあわせると、利得は２５％になると予測された。ＯＳ改善がディスク・アップグエードと組み合わされると、同様の２５％の利得が予測された。この改造のペアが実際に実装された。その結果の測定は、基本ＣＰＵ処理要求時間は作業負荷の予期せぬ変化のせいで減少したにもかかわらず、 $U_{CPU}$ は約２０％増加したことを示していた。よって、モデルはシステムの真の振舞に近い予測を提供していた。
　この例は非常に単純なモデルが興味のある性能の質問に答えるために使用出来ることを示している。コンピュータ・システムの詳細のどれほどわずかだけがモデルに表現されているかに気づくことが重要である。つまり、性能にとって重要な、そして修正のために考慮中の、システムの側面だけが表現されていた。例えば、モデル内にはメモリの明示的な表現はない。この単純さは待ち行列ネットワーク・モデルの大きな利点である。

「6.3.3.キャパシティ計画」に続きます。