この章の内容は次のとおりです。
キャッシュ・サイズ・レポートは、キャッシュ内にあるオブジェクトの数とサイズに基づいてキャッシュ・サイズを示します。このサイズは、バックアップ・コピー、索引やオーバーヘッドを考慮に入れていません。<local-scheme>
の<unit-calculator>
サブ要素をBINARY
に設定したキャッシュのサイズが報告されます。このキャッシュ・サイズ・レポートの名前は、timestamp
-cache-size.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013101-cache-size.txt
は、2009年1月31日の午前1時のキャッシュ・サイズ・レポートを表します。表6-1は、キャッシュ・サイズ・レポートの内容を示します。
表6-1 キャッシュ・サイズ・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
キャッシュ・サービスの名前 |
|
|
キャッシュの名前 |
|
|
キャッシュ内のオブジェクトの数 |
|
|
キャッシュ内のオブジェクトによって消費されたバイト数 |
|
|
キャッシュ内のオブジェクトによって消費されたメガバイト(MB)数 |
|
|
各オブジェクトの平均メモリー消費量 |
キャッシュの使用レポートは、キャッシュの使用(get、put、エビクションなど)に関する情報を提供します。このキャッシュの使用レポートの名前は、timestamp
-cache-usage.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2010013113-cache-usage.txt
は、2010年1月31日の午後1時のキャッシュ使用レポートを表します。表6-2は、キャッシュ使用レポートの内容を示します。
表6-2 キャッシュの使用レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
キャッシュ・サービスの名前 |
|
|
キャッシュの名前 |
|
|
キャッシュがフロント層(ローカル・キャッシュ)とバック層(リモート・キャッシュ)のどちらに配置されているのか。値は |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してputが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体で |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してgetが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体で |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してアクセスした合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でヒットだった |
|
|
前回レポートがリフレッシュされてからクラスタ全体でのキャッシュに対するミスの合計数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でミスだった |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュについて記憶域への書込みが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体で記憶域への書込み操作にかかった合計時間(ミリ秒) |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュのキャッシュ・ストアから読取りが実行された合計回数 |
|
|
前回レポートが実行されてからクラスタ全体でキャッシュのキャッシュ・ストアの読取りにかかった合計時間(ミリ秒) |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュについて障害が発生した合計回数 |
|
|
クラスタ全体のキュー・リンク・サイズの合計 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してエビクションが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してプルーニングが実行された合計回数 |
|
|
前回レポートがリフレッシュされてからクラスタ全体でプルーニング操作にかかった合計時間(ミリ秒) |
フェデレーション・デスティネーション・レポートは、レプリケートされたデータを受信するフェデレーション参加者の視点から送信レプリケーション統計を示します。フェデレーション・デスティネーション・レポートの名前はtimestamp
-federation-destination.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013101-federation-destination.txt
は、2009年1月31日の午前1時のレポートを表します。表6-3は、フェデレーション・デスティネーション・レポートの内容を示します。
表6-3 フェデレーション・デスティネーション・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
フェデレーション統計の対象メンバー |
|
|
送信者の名前 |
|
|
参加者の状態。 |
|
|
参加者のステータス。ステータスは次のとおりです。
|
|
|
送信レプリケート・メッセージの1秒当たりの現在使用中の帯域幅(メガビット) |
|
|
送信されたバイトの総数 |
|
|
送信されたキャッシュ・エントリの総数 |
|
|
送信されたジャーナル・レコードの総数。ジャーナル・レコードは、同一のトランザクションの一部である複数のキャッシュ・エントリで構成されます |
|
|
送信されたレプリケーション・メッセージの総数。レプリケーション・メッセージには、複数のジャーナル・レコードが含まれます。 |
|
|
未応答のレプリケーション・メッセージの総数 |
|
|
ジャーナル・レコードがキャッシュ内でレプリケートを待機する時間の90パーセンタイル値(ミリ秒)です |
|
|
レプリケーション・メッセージおよびネットワーク上の関連する応答メッセージの送信にかかった時間の90パーセンタイル値(ミリ秒)です |
|
|
レプリケーション・メッセージをデスティネーションに適用するのに要した時間の90パーセンタイル値(ミリ秒)です |
|
|
1秒当たりの送信バイト数 |
|
|
1秒当たりの送信メッセージ数 |
|
|
送信レプリケート・メッセージの1秒当たりの最大帯域幅(メガビット)。 |
|
|
エラーの説明。送信者の状態が |
|
|
参加者に構成された送信タイムアウト |
|
|
参加者に構成された場所のメタデータ |
フェデレーション・オリジン・レポートは、レプリケートされたデータを送信するフェデレーション参加者の視点から受信レプリケーション統計を示します。フェデレーション・オリジン・レポートの名前はtimestamp
-federation-origin.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013101-federation-origin.txt
は、2009年1月31日の午前1時のレポートを表します。表6-4は、フェデレーション・オリジン・レポートの内容を示します。
表6-4 フェデレーション・オリジン・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
フェデレーション統計の対象メンバー |
|
|
受信されたバイトの総数 |
|
|
受信されたジャーナル・レコードの総数。ジャーナル・レコードは、同一のトランザクションの一部である複数のキャッシュ・エントリで構成されます |
|
|
受信されたキャッシュ・エントリの総数 |
|
|
受信されたレプリケーション・メッセージの総数。レプリケーション・メッセージには、複数のジャーナル・レコードが含まれます |
|
|
未応答のレプリケーション・メッセージの総数 |
|
|
レプリケーション・メッセージをデスティネーションに適用するのに要した時間の90パーセンタイル値(ミリ秒)です。 |
|
|
ジャーナル・レコードがキャッシュ内でレプリケートを待機する時間の90パーセンタイル値(ミリ秒)です |
|
|
1秒当たりの受信バイト数 |
|
|
1秒当たりの受信メッセージ数 |
キャッシュ・サイズ・レポートは、フェデレーション参加者のステータスを示します。フェデレーション・ステータス・レポートの名前はtimestamp
-federation-status.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013101-federation-status.txt
は、2009年1月31日の午前1時のキャッシュ・サイズ・レポートを表します。表6-5は、フェデレーション・ステータス・レポートの内容を示します。
表6-5 フェデレーション・ステータス・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
フェデレーション統計の対象メンバー |
|
|
送信者の名前 |
|
|
参加者の状態。 |
|
|
エラーの説明。送信者の状態が |
フラッシュ・ジャーナル・レポートには、フラッシュ・メモリーにデータがどれくらい効率的に保存されているかを確認するために役立つ統計が表示されます。このフラッシュ・ジャーナル・レポートの名前はtimestamp
-flashjournal.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2010013113-flashjournal.txt
は、2010年1月31日の午後1時のフラッシュ・ジャーナル・レポートを表します。表6-6は、フラッシュ・ジャーナル・レポートの内容を示します。
表6-6 フラッシュ・ジャーナル・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
フラッシュ・ジャーナルの統計の対象メンバー |
|
|
現在使用中のジャーナル・ファイルの数 |
|
|
このジャーナルを使用しているアクティブな |
|
|
このジャーナルに現在保存されているバイト単位のデータ量 |
|
|
このジャーナルのすべてのジャーナル・ファイルの合計サイズ |
|
|
まだジャーナルに格納されていない、シリアライズされた値の数 |
|
|
バックログのバイト単位の最大サイズ。バックログは、まだジャーナルに格納されていない、シリアライズされた値の数です。クライアント・スレッドは、この制限を超えるとブロックされ、バックログが制限を下回るまでブロックされたままになります。 |
|
|
プール内の使用可能なバッファのバイト単位での合計サイズ |
JCache構成レポートには、JCacheキャッシュで設定された構成オプションが表示されます。Cacheキャッシュは、キャッシュが作成される際にJCache APIを使用してプログラムから構成されます。このレポートの名前はtimestamp
-jcache-configuration.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013113-jcache-configuration.txt
は、2009年1月31日の午後1時の管理レポートを表します。表6-7は、JCache構成レポートの内容を示します。
表6-7 JCache構成レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
キャッシュを作成したJCache |
|
|
キャッシュの名前 |
|
|
キャッシュが必要とするキーの型です。 |
|
|
キャッシュが必要とする値の型です。 |
|
|
キャッシュの管理が有効化されているかどうかを示します |
|
|
キャッシュのパフォーマンス統計が収集されているかどうかを示します |
|
|
キャッシュ操作がリードスルー・モードかどうかを示します |
|
|
キャッシュ操作がライトスルー・モードかどうかを示します |
|
|
キャッシュが値による格納または参照による格納のどちらのセマンティクスを使用しているかを示します。 |
JCache統計レポートには、JCacheキャッシュがどれくらい効率的に実行されているかを評価するのに使用される情報が含まれます。このレポートの名前はtimestamp
-jcache-statistics.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013113-jcache-statistics.txt
は、2009年1月31日の午後1時の管理レポートを表します。表6-8は、JCache統計レポートの内容を示します。
表6-8 JCache統計レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
キャッシュを作成したJCache |
|
|
キャッシュの名前 |
|
|
|
|
|
既存のエントリの置換操作を含むput操作の総数です |
|
|
|
|
|
成功した |
|
|
成功しなかった |
|
|
キャッシュからのエビクションの総数です。エビクションは、スペースを開放するため、キャッシュによって開始されます。エビクションは、 注意: この属性は、Coherence JCacheプロバイダでは実装されていません。 |
|
|
|
|
|
|
|
|
|
|
|
エントリを返したキャッシュ・リクエストの割合です。この割合は、キャッシュ・ヒットをキャッシュの |
|
|
エントリを返さなかったキャッシュ・リクエストの割合です。この割合は、キャッシュ・ミスをキャッシュの |
管理レポートには、管理フレームワークがすべてのMBeanに対してタイムリな管理データを表示しているかどうかを確認するためのリフレッシュ統計があります。この管理レポートの名前はtimestamp
-management.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013113-Management.txt
は、2009年1月31日の午後1時の管理レポートを表します。表6-9は、管理レポートの内容を示します。
表6-9 管理レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
現在設定されているリフレッシュ・ポリシー。このポリシーは、リモート・モデルのデータのリフレッシュ方法を決定します。 |
|
|
このモデルが、対応するメンバーから前回取得されたときのタイムスタンプ。ローカル・サーバーの場合はローカル時間になります。 |
|
|
MBeanサーバーによって情報が予測的にリフレッシュされ、その情報がアクセスされなかった回数 |
|
|
統計が最後にリセットされてから取得されたスナップショットの合計数 |
|
|
MBeanサーバーによって予測的なアルゴリズムが使用され、MBean情報がリフレッシュされた回数 |
|
|
この管理メンバーがリモートMBean属性のリフレッシュ試行中にタイムアウトした回数 |
メモリー・ステータス・レポートには、各メンバーおよびグリッド全体のメモリー消費を把握するために役立つ統計が含まれます。メモリー・ステータス・レポートは、レポート・グループの一部として実行する必要があります。メモリー・ステータス・レポートは、プラットフォームMBeanの情報に依存しています。MBeanのフィルタリングを参照してください。メモリー・ステータス・レポートの名前はtimestamp
-memory-status.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013115-memory-status.txt
は、2009年1月31日の午後3時のメモリー・ステータス・レポートを表します。表6-10は、メモリー・ステータス・レポートの内容を示します。
表6-10 メモリー・ステータス・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
前回のJVM起動からの経過時間 |
|
|
メモリー統計の対象メンバー |
|
|
ガベージ・コレクタの名前 |
|
|
前回のJVM起動以降のガベージ・コレクションの回数 |
|
|
前回のレポート・リフレッシュ以降のガベージ・コレクションの回数 |
|
|
JVMが起動後にガベージ・コレクションに費やした時間(ミリ秒) |
|
|
前回のレポート・リフレッシュ以降にJVMがガベージ・コレクションに費やした時間(ミリ秒) |
|
|
最後のガベージ・コレクションの開始時間 |
|
|
最後のガベージ・コレクションの合計時間 |
|
|
最後のガベージ・コレクションの停止時間 |
|
|
レポート実行時点におけるコミット済ヒープ・バイト数 |
|
|
レポート実行時点における初期化済ヒープ・バイト数 |
|
|
JVMが起動後に使用した最大バイト数 |
|
|
レポート実行時点でJVMが使用していたバイト数 |
ネットワーク・ヘルス詳細レポートには、ネットワーク通信の状態を確認するためのメンバー・レベルの詳細が含まれます。このネットワーク・ヘルス詳細レポートの名前はtimestamp
-network-health-detail.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013114-network-health-detail.txt
は、2009年1月31日の午後2時のネットワーク・ヘルス詳細レポートを表します。表6-11は、ネットワーク・ヘルス詳細レポートの内容を示します。
表6-11 ネットワーク・ヘルス詳細レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
管理情報が、対応するノードから前回取得されたときのシステム時刻。ローカル・サーバーはローカル時間を表示します。 |
|
|
ネットワーク統計の対象メンバー。 |
|
|
メンバーにおけるパブリッシャの成功率。この値が、ネットワーク・ヘルス・ファイルのバッチ(表6-12を参照)に示される |
|
|
メンバーにおける受信側の成功率。この値が、ネットワーク・ヘルス・ファイルのバッチ(表6-12を参照)に示される |
|
|
メンバーから送信されたネットワーク・パケットの総数 |
|
|
前回のレポート・リフレッシュ以降にメンバーから送信されたパケットの数 |
|
|
メンバーから再送信されたネットワーク・パケットの総数。パケットの受信側が無効なパケットを受信した場合、または適切な時間内に確認パケットが送信されなかった場合、パケットは再送信されます。 |
|
|
前回のレポート・リフレッシュ以降にメンバーから再送信されたパケットの数 |
|
|
複数回受信したパケットの総数 |
|
|
前回のレポート・リフレッシュ以降に複数回受信したパケットの数 |
|
|
メンバーが受信したパケットの総数 |
|
|
前回のレポート・リフレッシュ以降にメンバーが受信したパケットの総数 |
ネットワーク・ヘルス・レポートには、ネットワーク通信の状態を確認するために役立つ主要な集計情報が含まれます。このネットワーク・ヘルス・レポートの名前はtimestamp
-network-health.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013113-network-health.txt
は、2009年1月31日の午後1時のネットワーク・ヘルス・レポートを表します。表6-12は、ネットワーク・ヘルス・レポートの内容を示します。
表6-12 ネットワーク・ヘルス・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
クラスタ内のメンバーにおける受信側の最小成功率。この値が、 |
|
|
グリッド全体における受信側の成功率。この値が90%よりも低い場合、ネットワーク・ヘルス詳細レポートを分析してください。 |
|
|
クラスタ内のメンバーにおけるパブリッシャの最小成功率。この値が、 |
|
|
グリッド全体におけるパブリッシャの成功率。この値が90%よりも低い場合、ネットワーク・ヘルス詳細レポートを分析してください。 |
ノード・リスト・レポートは、クラスタ・メンバーの識別に役立つ情報を提供します。ノード識別子(nodeId
)は一時的であるという性質をもつため、レポータは、メンバーのリストとユーザー定義のメンバーの識別情報をログに出力します。『Oracle Coherenceでのアプリケーションの開発』の<member-identity要素を参照してください。このノード・リスト・レポートの名前は
timestamp
-nodes.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013101-nodes.txt
は、2009年1月31日の午前1時のノード・リスト・レポートを表します。表6-13は、ノード・リスト・レポートの内容を示します。
表6-13 ノード・リスト・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
情報がリモート・メンバーからリフレッシュされた時間。この時刻がバッチに出力された他の行のリフレッシュ時刻と異なる場合、このメンバーは適時に応答しなかったことになります。この現象は一般に、ガベージ・コレクションを実行しているメンバーで発生します。リフレッシュ日付が古いメンバーに関する情報は信頼できません。 |
|
|
数値のメンバー識別子 |
|
|
メンバーのユニキャスト・アドレス |
|
|
メンバー名 |
|
|
メンバーのプロセス名 |
|
|
メンバーのロール名 |
|
|
メンバーのコンピュータ名 |
|
|
メンバーのラック名 |
|
|
メンバーのサイト名 |
永続性詳細レポートは、キャッシュ永続性が特定のサービスおよびノードでどのように実行されているかに関する詳細な情報を示します。永続性詳細レポートの名前はtimestamp
-persistence-detail.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013101-persistence-detail.txt
は、2009年1月31日の午前1時の永続性詳細レポートを表します。表6-14は、永続性詳細レポートの内容を示します。
表6-14 永続性詳細レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
パーティション化キャッシュ・サービスの名前 |
|
|
このサービスで使用される現在の永続性モードは、次のとおりです。
|
|
|
永続性統計の対象メンバー |
|
|
アクティブな永続性操作により変更キャッシュ操作に追加された平均待機時間(ミリ秒) |
|
|
アクティブな永続性操作により変更キャッシュ操作に追加された最大待機時間(ミリ秒)。 |
|
|
アクティブな永続性で使用される領域の量(バイト) |
|
|
アクティブな永続性で使用するファイル・システムの合計サイズ(バイト) |
|
|
アクティブな永続性のファイル・システムで使用可能な残りの領域(バイト) |
|
|
スナップショットを格納するファイル・システムの合計サイズ(バイト) |
|
|
スナップショットを格納するためにファイル・システムで使用可能な残りの領域(バイト) |
永続性レポートは、キャッシュ永続性が特定のサービスでどのように実行されているかに関する情報を示します。永続性レポートの名前はtimestamp
-persistence.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013101-persistence.txt
は、2009年1月31日の午前1時の永続性レポートを表します。表6-15は、永続性レポートの内容を示します。
表6-15 永続性レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
パーティション化キャッシュ・サービスの名前 |
|
|
このサービスで使用される現在の永続性モードは、次のとおりです。
|
|
|
アクティブな永続性で使用される領域の量(バイト) |
|
|
アクティブな永続性操作により変更キャッシュ操作に追加されたすべてのノードの平均待機時間(ミリ秒) |
|
|
アクティブな永続性操作により変更キャッシュ操作に追加されたすべてのノードの最大待機時間(ミリ秒)。 |
プロキシ・レポートには、プロキシ・サーバーに関する情報およびクライアントに転送された情報が含まれます。このプロキシ・レポートの名前はtimestamp
-network-report-proxy.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013101-report-proxy.txt
は、2009年1月31日の午前1時のプロキシ・レポートを表します。表6-16は、プロキシ・レポートの内容を示します。
表6-16 プロキシ・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
このモデルが、対応するメンバーから前回取得されたときのタイムスタンプ。ローカル・サーバーの場合はローカル時間になります。 |
|
|
プロキシ・サービスの名前 |
|
|
プロキシ・サービスのIPアドレスおよびポート |
|
|
数値のメンバー識別子 |
|
|
プロキシ・サービスの現在の接続数 |
|
|
プロキシ・サービスによる送信のキューに入れられたバイト数 |
|
|
プロキシ・サービスによるキューに入れられたメッセージ数 |
|
|
前回のレポート・リフレッシュ以降にプロキシ・サービスから送信されたバイト数 |
|
|
前回のレポート・リフレッシュ以降にプロキシ・サービスが受信したバイト数 |
|
|
前回のレポート・リフレッシュ以降にプロキシ・サービスから送信されたメッセージ数 |
|
|
前回のレポート・リフレッシュ以降にプロキシ・サービスが受信したメッセージ数 |
プロキシHTTPレポートは、プロキシ・サーバーに対して構成されているHTTPアクセプタに関する情報を提供します。このプロキシ・レポートの名前はtimestamp
-report-proxy-http.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2009013101-report-proxy-http.txt
は、2009年1月31日の午前1時のプロキシ・レポートを表します。表6-17は、プロキシHTTPレポートの内容を示します。
表6-17 プロキシHTTPレポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
このモデルが、対応するメンバーから前回取得されたときのタイムスタンプ。ローカル・サーバーの場合はローカル時間になります。 |
|
|
プロキシ・サービスの名前 |
|
|
HTTPサーバーのタイプ、またはHTTPプロトコルを使用していな場合は |
|
|
プロキシ・サービスのIPアドレスおよびポート |
|
|
数値のメンバー識別子 |
|
|
HTTPリクエストの平均サイズ |
|
|
HTTPレスポンスの平均サイズ |
|
|
HTTPリクエストの平均処理時間(ミリ秒単位) |
|
|
エラーが発生したHTTPリクエストの数 |
|
|
HTTPサーバーが起動されてから、または統計が最後にリセットされてからのリクエストの数 |
|
|
100から199の範囲のHTTPレスポンスの数 |
|
|
200から299の範囲のHTTPレスポンスの数 |
|
|
300から399の範囲のHTTPレスポンスの数 |
|
|
400から499の範囲のHTTPレスポンスの数 |
|
|
500から599の範囲のHTTPレスポンスの数 |
RAMジャーナル・レポートには、RAMメモリーにデータがどれくらい効率的に保存されているかを確認するために役立つ統計が表示されます。このRAMジャーナル・レポートの名前はtimestamp
-ramjournal.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2010013113-ramjournal.txt
は、2010年1月31日の午後1時のRAMジャーナル・レポートを表します。表6-18は、RAMジャーナル・レポートの内容を示します。
表6-18 RAMジャーナル・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
RAMジャーナルの統計の対象メンバー |
|
|
現在使用中のジャーナル・ファイルの数 |
|
|
このジャーナルを使用しているアクティブな |
|
|
このジャーナルに現在保存されているバイト単位のデータ量 |
|
|
このジャーナルのすべてのジャーナル・ファイルの合計サイズ |
サービス・レポートには、サービスのヘルスおよびパフォーマンスをモニタリングするための情報が含まれます。Request Count
およびTask Count
の各値は、サービスのパフォーマンスとスループットを確認する場合に使用します。RequestPendingCount
およびTask Backlog
の各値は、容量の問題やブロックされたプロセスの特定に使用します。Task Hung Count
、Task Timeout Count
、Thread Abandoned Count
、およびRequest Timeout Count
の各値は、システムで発生した実行の失敗数を示します。このサービス・レポートの名前はtimestamp
-service.txt
です。ここで、タイムスタンプはYYYYMMDDHH
形式になります。たとえば、ファイル2010013113-service.txt
は、2010年1月31日の午後1時のサービス・レポートを表します。表6-19は、サービス・レポートの内容を示します。
表6-19 サービス・レポートの内容
列 | データ型 | 説明 |
---|---|---|
|
|
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。 |
|
|
レポートの各リフレッシュのタイムスタンプ |
|
|
サービス名 |
|
|
数値のメンバー識別子 |
|
|
サービス情報がリモート・メンバーから更新されたシステム時間 |
|
|
前回のレポート・リフレッシュ以降のリクエスト数 |
|
|
レポート実行時点における未処理のリクエスト数 |
|
|
レポート実行時点における未処理リクエストの待機時間 |
|
|
前回のレポート・リフレッシュ以降のリクエストのタイムアウト回数 |
|
|
前回のレポート・リフレッシュ以降に実行されたタスクの数 |
|
|
レポート実行時点におけるタスクのバックログ |
|
|
前回のレポート・リフレッシュ以降のタスクのタイムアウト回数 |
|
|
前回のレポート・リフレッシュ以降にハングしたタスクの数 |
|
|
前回のレポート・リフレッシュ以降に破棄されたスレッドの数 |