バッファプール統計

バッファプールにロードされた各オブジェクトには、そのオブジェクトに関する情報を含むディレクトリエントリが必要です。 これらのディレクトリエントリのためのスペースは、バッファプールに割り当てられます。

ディレクトリエントリによって使用されるスペースが割り当てられた後、残りのスペースは、テキストレコード（サイズはデフォルトで 4 KB）と呼ばれるブロックに分割されます。 オブジェクトは、サイズに応じて 1 つまたは複数のテキストレコードを占有できます。

バッファプールのサイズは、パラメータモジュールの NTBPI マクロ、または『パラメータリファレンス』ドキュメントで説明されている BPI プロファイルパラメータで指定できます。

INITIALIZE コマンドを使用してバッファプールを再初期化すると、既存のバッファプールのテキストレコードのサイズを変更することができます。

デフォルトのテキストレコードのサイズは、4 KB に設定されています。 ただし、多くの小さいオブジェクトで構成されるアプリケーションを使用する場合は、2 KB に減らすことをお勧めします。 これにより、バッファプール内の未使用のスペースの比率が減少しますが、アルゴリズム 2（『オペレーション』ドキュメントの「METHOD=S」を参照）がより頻繁に呼び出されるようになります。

バッファプールは次の場合に初期化されます。

• バッファプールの最初の開始、

• INITIALIZE SYSBPM ダイレクトコマンドの実行、または

• GBP オペレーティングプログラムの REFRESH コマンドの実行。詳細については、『オペレーション』ドキュメントの「グローバルバッファプールのオペレーティング機能」も参照してください。

テキストレコードサイズの合計とオブジェクトサイズの合計との差は、テキストレコードセクションの未使用のサイズを表し、システム管理者がテキストレコードのサイズを変更するかどうかの指標とすることもできます。

この値は、75 ％を著しく下回らないようにしてください。 バッファプールがほとんどいっぱいの場合、75 ％を超える値は、バッファプールが適切に使用されていることを示します。 使用率が 75 ％を著しく下回る場合は、テキストレコードのサイズを縮小する必要があります。

ヒント:
バッファプールがほとんどいっぱい、つまり、［Text Records - Used］フィールドの値がほぼ 100 ％の場合、75 ％を超える値は、バッファプールが適切に使用されていることを示します。 使用率が 75 ％を著しく下回る場合は、テキストレコードのサイズを縮小する必要があります。

使用回数では、現在オブジェクトを実行しているすべてのアプリケーションがカウントされます。 オブジェクトが現在使用されていない場合、そのオブジェクトの使用回数は 0（ゼロ）に変わります。

検索が正常に終了した場合、オブジェクトはバッファプールまたはバッファプールキャッシュ内で検出され、Natural システムファイルからのロードは不要となり、コールおよび I/O が回避されます。

高速検索コールでは、内部高速検索テーブルを使用して、バッファプール内のオブジェクトを検索します。 詳細については、「内部高速検索テーブル」を参照してください。

この場合、ライブラリ（名前、データベース ID、ファイル番号）、および前回正常に終了した検索コールのバッファプール内のオブジェクトの場所が、オブジェクトの検索に再度使用されます。

これは、オブジェクトを検索するための最も効果的な方法です。

失敗した高速検索コールは、内部高速検索テーブルを使用して、オブジェクトがバッファプール内の前回の位置に見つからなかったことを示します（「パフォーマンスの考慮事項」の関連するセクションを参照）。

これは、オブジェクトがバッファプールから削除されたか、または別の位置に移動された場合に発生します。 高速検索コールの失敗により、通常検索コールが発生しますが、Natural ランタイムではオブジェクトを含むライブラリが記憶されているため、steplib 検索は実行されません。

［Normal after Quick］の値は、常に［Quick Locate Calls - failed］の数と同じです。

高速後の通常コールは、要求されたオブジェクトがまだバッファプール内にあるが、別の位置にある場合に正常に終了します。

高速後の通常コールの失敗は、要求されたオブジェクトがバッファプールで使用できなくなったことを示します。 その結果、オブジェクトは、内部高速検索テーブル内のライブラリエントリを使用して、システムファイルから再ロードされます（「パフォーマンスの考慮事項」の関連するセクションを参照）。

通常検索コールでは、内部高速検索テーブルを使用せずに、バッファプール内のオブジェクトが検索されます（「パフォーマンスの考慮事項」の関連するセクションを参照）。

通常検索コールは、LOGON システムコマンドが実行された後に、Natural セッション内で最初に参照された場合に常に発生します。 高速検索コールと比較して、Natural ランタイムでは、オブジェクトが存在するライブラリはまだ認識されません。

失敗した通常検索コールは、名前および存在するライブラリによって識別されたオブジェクトが、バッファプール内に見つからなかったことを示します。

失敗した通常検索は、バッファプールキャッシュまたはシステムファイルからのロード、あるいは steplib チェーン内の次のライブラリの通常検索コールによって発生します。

steplib 検索が正常に実行されなかった通常検索コールでは、バッファプールキャッシュまたはシステムファイルからオブジェクトはロードされません。

［STEPLIB Searches］では、現在のライブラリにも、どの steplib やシステムファイルにも含まれていないオブジェクトの検索コールはカウントされません（エラーメッセージ「不正なコマンドです。またはライブラリにプログラムがありません」）。 不正なプログラミングのために失敗した検索コールは、［Normal Locate Calls - failed］のカウンタに追加されます。

［STEPLIB Searches］の数は、次の公式を使用して計算されます。

［Normal Locate Calls - failed］ - （［Number Loads into BP］ - ［Normal after Quick - failed］）

［STEPLIB Searches］の数が少ないほど、バッファプールのパフォーマンスパフォーマンスは向上します。

「Steplibs での検索」も参照してください。

バッファプールへのロード（ストレージ割当要求）は、データベースからのロードまたはバッファプールキャッシュからのロードによってトリガすることができます。

1 つのオブジェクトをロードするために複数のロードコールが必要な場合があるため、この値は、最新のバッファプール更新以降に実行されたオブジェクトのロードの実際の数となります。

オブジェクトをロードする場合、バッファプールマネージャでは異なる検索アルゴリズムが使用されます。『オペレーション』ドキュメントの「METHOD=S」および「METHOD=N」を参照してください。

次のいずれかの理由によってロード操作がキャンセルされた場合、オブジェクトのロードは終了できません。

• オブジェクトの同時ロードが発生した。［Loads from DB - concurrent］を参照してください。

• オブジェクトのロード中、Adabas レスポンスコードが返される。

• オブジェクトのロード中、SYSBPM 削除操作がそのオブジェクトに対して実行される。

オブジェクトの同時ロードは、同時に実行されている複数の Natural セッションが同じオブジェクトを要求した場合に発生します。 オブジェクトが 1 つのセッションによってロードされている間、他のセッションが同じオブジェクトを要求し、ロードが完了する前にオブジェクトのロードを開始します。 この場合、同じオブジェクトが複数回ロードされます。

オブジェクトのロードを終了する最初のセッションは、他のセッションのオブジェクトをバッファプールからの削除対象としてマークします。 その場合、他のセッションはオブジェクトのロードを中止し、削除対象としてマークされたオブジェクトをバッファプールから削除して、最初のセッションによって正常にロードされたオブジェクトを使用します。

カウンタ［Loads from DB - finished］および［Loads from DB - concurrent］によって計算されたオブジェクトの数は、通常同じです。 この数は、両方のセッションがロードを終了した後に初めて同時ロードが検出された場合にのみ異なります。

システムファイルアクセスの数は、次のように計算されます。

• Adabas システムファイル：［Load Calls］の数 + ［Loads from DB］（上記参照）。 合計数には、Adabas RC コールは含まれません。

• VSAM システムファイル：［Load Calls］の数。

このフィールドには、ストレージ割り当て要求がアルゴリズム 2 の検索条件を満たした回数が表示されます。詳細については、『オペレーション』ドキュメントの「METHOD=S」を参照してください。

このフィールドは、検索がバッファプールの先頭から実行された回数を示します。 その数は、バッファプール内のサイクルの頻度の見積りをラップアラウンド方式で示します。

［Number Load Cycles］が最後に増加した日時。

このフィールドは、ロックされたバッファプールエントリが割り当て要求を満たせなかったために、それらのエントリのチェーンを解除する必要があった回数を示します。

スロットの数、つまりハッシュテーブルのサイズは、テキストレコードの数に基づいて内部で計算されます。

競合は、ハッシュアルゴリズムによって 2 つの異なるオブジェクトの名前が同じスロットにマップされた場合に発生します。 その場合、別のスロットを見つけるために競合の解決が使用されます。

また、これらのスロットと使用されたすべてのスロットとの比率も表示されます。

この比率は、バッファプールの効率の指標として使用できます。 この数が大きいほど、バッファプールのパフォーマンスは向上します。 この比率は、1 つのバッファプールセッションから次のセッションへのパフォーマンスの主要な指標です。

バッファプールが最後に完全に再利用されてからの時、分、秒（hh:mm:ss）単位の時間（ラップアラウンド）。

オブジェクトはバッファプールに次々に（順番に）ロードされ、最初にバッファプールの先頭を埋め、最後に末尾を埋めます。 バッファプールの末尾に到達すると、バッファの末尾はラップアラウンドされ、バッファプールの先頭で次のオブジェクトが再びロードされます。

バッファプールが初めて完全にいっぱいになると、前のラップアラウンドサイクルでロードされ、現在ロックされていない（常駐または使用中としてマークされている）オブジェクトが、バッファにロードされた新しいオブジェクトで上書きされます。

バッファプールにロードされたすべてのオブジェクトに、オブジェクトの名前、オブジェクトが保存されているライブラリ、バッファプールへのロードの［BP Load Time］タイムスタンプなどの情報を含むディレクトリエントリが割り当てられます。

［Wrap Time Last］は、オブジェクトがバッファプールにロードされるたびに評価されます。 ［Wrap Time Last］は、オブジェクトの最後のロード（［BP Load Time］）とオブジェクトの最後の上書きとの間の期間を示します。

ラップアラウンドサイクルの期間が長くなるほど、バッファプールのパフォーマンスは向上します。 この期間は、ユーザートラフィックが通常の営業時間より少ない夜間や週末には大幅に異なります。

バッファプールが初期化または更新されてからの 1 回のラップアラウンドサイクルの時、分、秒（hh:mm:ss）単位の平均時間。

［Wrap Time Avg］は、バッファプールの存続時間をラップアラウンドサイクルの数で除算して計算されます。

［Wrap Time Avg］と比較した［Wrap Time Last］では、バッファプールが現在平均よりも頻繁に使用されているかどうかが示されます。

この値は、正常に終了した Get コールを正常に終了した Put コールで除算して計算されます。 この値は、再利用ファクタ全体、つまり、バッファプールキャッシュに 1 回ロードされたオブジェクトをバッファプールに正常に再ロードできる回数を示します。 値が大きいほど、バッファプールキャッシュの効率はよくなります。

［Object Reuse Factor］の例：
5.70 の比率は、バッファプールキャッシュにロードされたオブジェクトがバッファプールに平均 5.7 回スワップされたことを示します。

オブジェクトはバッファプールキャッシュに次々に（順番に）ロードされ、最初にバッファプールキャッシュの先頭を埋め、最後に末尾を埋めます。 バッファプールキャッシュの末尾に到達すると、バッファプールキャッシュの末尾はラップアラウンドされ、バッファプールキャッシュの先頭で次のオブジェクトが再びロードされます。 バッファプールキャッシュが初めて完全にいっぱいになると、前のラップアラウンドサイクルでロードされたオブジェクトが、バッファにロードされた新しいオブジェクトで上書きされます。

バッファプールキャッシュにロードされた各オブジェクトに、オブジェクトの名前、オブジェクトが保存されているライブラリ、バッファプールキャッシュへロードされたときの［BPC Load Time］タイムスタンプなどの情報を含むディレクトリエントリが割り当てられます。

［Wrap Time Last］は、オブジェクトがバッファプールキャッシュにロードされるたびに評価されます。 ［Wrap Time Last］は、オブジェクトの最後のロード（［BPC Load Time］）とオブジェクトの最後の上書きとの間の期間を示します。

ラップアラウンドサイクルの期間が長くなるほど、バッファプールキャッシュのパフォーマンスは向上します。 この期間は、ユーザートラフィックが通常の営業時間より少ない夜間や週末には大幅に異なります。

［Wrap Time Avg］は、バッファプールキャッシュの存続時間をラップアラウンドサイクルの数で除算して計算されます。

［Wrap Time Avg］と比較した［Wrap Time Last］では、バッファプールキャッシュが現在平均よりも頻繁に使用されているかどうかが示されます。

この値は、バッファプールが、Natural システムファイルの FNAT または FUSER ではなく、バッファプールキャッシュからロードできたオブジェクトの比率を表します。 値が大きいほど、キャッシュの効率はよくなります。

steplibs のチェーン内のオブジェクトの検索により、バッファプールがバッファプールキャッシュに送信する Search コールの数が増加する場合があることに注意してください。 ただし、オブジェクトが steplib で見つからない場合があるため、これらのコールでは、正常な Get コールまたは Natural システムファイルからのロードは実行されません。 ［Get / Search %］では、頻繁に使用される steplibs の長いチェーンの検索は考慮されません。 全体的なパフォーマンスを向上させるため、使用する steplibs はできるだけ少なくすることをお勧めします。

［Get / Search %］値の例：
70% の値は、バッファプールにロードされたすべてのオブジェクトの 70 ％がバッファプールキャッシュから取得され、30 ％がシステムファイルからロードされたことを示します。

PF8
（Load）

［Buffer Pool Load/Locate Statistics］画面が表示されます。

PF8
（Gen）

［General Buffer Pool Statistics］画面が表示されます。