6 レポータの内容の分析

Coherenceでは、発生する可能性のある使用上および構成上の問題を管理者や開発者が効率的に分析できるよう、すぐに利用可能なレポートが提供されます。Coherence*Webに固有のレポートについては、『Oracle Coherence Oracle Coherence*Webユーザーズ・ガイド』のパフォーマンス・レポートの実行に関する項を参照してください。

この章には次の項が含まれます:

キャッシュ・サイズ・レポートについて
キャッシュの使用レポートについて
フラッシュ・ジャーナル・レポートについて
管理レポートについて
メモリー・ステータス・レポートについて
ネットワーク・ヘルス詳細レポートについて
ネットワーク・ヘルス・レポートについて
ノード・リスト・レポートについて
プロキシ・レポートについて
RAMジャーナル・レポートについて
サービス・レポートについて

6.1 キャッシュ・サイズ・レポートについて

キャッシュ・サイズ・レポートは、必要に応じて実行することも、レポート・バッチの一部に含めて実行することもできます。このレポートでは、キャッシュの<local-scheme>の<unit-calculator>サブ要素をBINARYに設定する必要があります。キャッシュ・サイズ・ファイルはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-cache-size.txtが付きます。たとえば、2009年1月31日午前1時に作成されたファイルの名前は、2009013101-cache-size.txtになります。表6-1は、キャッシュ・サイズ・レポートの内容を示しています。

表6-1 キャッシュ・サイズ・レポートの内容

列	データ型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Cache Name	String	キャッシュの名前。
Cache Size	Double	キャッシュ内のオブジェクトの数。
Memory Bytes	Double	キャッシュ内のオブジェクトによって消費されたバイト数。これにはインデックスやオーバーヘッドは含まれません。
MemoryMB	Double	キャッシュ内のオブジェクトによって消費されたMB。これにはインデックスやオーバーヘッドは含まれません。
Avg Object Size	Double	各オブジェクトの平均メモリー消費量。

6.2 キャッシュの使用レポートについて

キャッシュの使用レポートは、キャッシュの使用(get、put、エビクションなど)に関する情報を提供します。このレポートはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-cache-usage.txtが付きます。たとえば、2010年1月31日午後1時に作成されたファイルの名前は、2010013113-cache-usage.txtになります。表6-2は、キャッシュの使用レポートの内容を示しています。

表6-2 キャッシュの使用レポートの内容

列	データ型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
Service	String	キャッシュ・サービスの名前。
Cache Name	String	キャッシュの名前。
Tier	String	値は`front`または`back`です。キャッシュがフロント層(ローカル・キャッシュ)とバック層(リモート・キャッシュ)のどちらに配置されているのかを示します。
Total Puts	Double	前回レポートが実行されてからクラスタ全体でキャッシュに対してputが実行された合計回数。
Total Puts Milliseconds	Double	前回レポートが実行されてからクラスタ全体でput()呼出しごとにかかった時間(PutsMillis)の合計(ミリ秒)。
Total Gets	Double	前回レポートが実行されてからクラスタ全体でキャッシュに対してgetが実行された合計回数。
Total Gets Milliseconds	Double	前回レポートが実行されてからクラスタ全体で`get()`呼出しごとにかかった時間(GetsMillis)の合計(ミリ秒)。
Total Hits	Double	前回レポートが実行されてからクラスタ全体でのキャッシュに対するヒットの合計数。
Total Hits Milliseconds	Double	前回レポートが実行されてからクラスタ全体でヒットだった`get()`呼出しごとにかかった時間(HitsMillis)の合計(ミリ秒)。
Total Misses	Double	前回レポートが実行されてからクラスタ全体でのキャッシュに対するミスの合計数。
Total Misses Milliseconds	Double	前回レポートが実行されてからクラスタ全体でミスだった`get()`呼出しごとにかかった時間(MissesMillis)の合計(ミリ秒)。
Total Writes	Double	前回レポートが実行されてからクラスタ全体でキャッシュについて記憶域への書込みが実行された合計回数。
Total Writes Milliseconds	Double	前回レポートが実行されてからクラスタ全体で記憶域への書込み操作にかかった時間(WritesMillis)の合計(ミリ秒)。
Total Reads	Double	前回レポートが実行されてからクラスタ全体でキャッシュのキャッシュ・ストアから読取りが実行された合計回数。
Total Read Milliseconds	Double	前回レポートが実行されてからクラスタ全体でキャッシュのキャッシュ・ストアの読取りにかかった時間の合計(ミリ秒)。
Total Failures	Long	前回レポートが実行されてからクラスタ全体でキャッシュについて記憶域で障害が発生した合計回数。
Total Queue	Long	クラスタ全体のキュー・リンク・サイズの合計。
evictions	Long	前回レポートが実行されてからクラスタ全体でキャッシュに対してエビクションが実行された合計回数。
Cache Prunes	Long	前回レポートが実行されてからクラスタ全体でキャッシュに対してプルーニングが実行された合計回数。
Cache Prunes Milliseconds	Long	前回レポートが実行されてからクラスタ全体でプルーニング操作にかかった時間(PrunesMillis)の合計(ミリ秒)。

6.3 フラッシュ・ジャーナル・レポートについて

フラッシュ・ジャーナル・レポートには、フラッシュ・メモリーにデータがどれくらい効率的に保存されているかを確認するために役立つ統計が表示されます。このレポートはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-flashjournal.txtが付きます。たとえば、2010年1月31日午後1時に作成されたファイルの名前は、2010013113-flashjournal.txtになります。表6-3は、キャッシュの使用レポートの内容を示しています。

表6-3 フラッシュ・ジャーナル・レポートの内容

列	型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
Node ID	Long	フラッシュ・ジャーナルの統計の対象メンバー。
FileCount	Integer	現在使用中のジャーナル・ファイルの数。
BinaryStoreCount	Integer	このジャーナルを使用しているアクティブな`JournalBinaryStore`オブジェクトの数。
TotalDataSize	Long	このジャーナルに現在保存されているバイト単位のデータ量。
TotalFileSize	Long	このジャーナルのすべてのジャーナル・ファイルの合計サイズ。
BacklogCount	Integer	永続化されていないシリアライズ値の数。
BacklogSize	Integer	バックログのバイト単位の最大サイズ。バックログとは、永続化されていないシリアライズ値の量のことです。クライアント・スレッドは、この制限を超えるとブロックされ、バックログが制限を下回るまでブロックされたままになります。
PoolSize	Integer	プール内の使用可能なバッファのバイト単位での合計サイズ。

6.4 管理レポートについて

管理レポートには、管理フレームワークがすべてのMBeanに対してタイムリな管理データを表示しているかどうかの確認に使用されるリフレッシュ統計があります。管理ファイルはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-Management.txtが付きます。たとえば、2009年1月31日午後1時に作成されたファイルの名前は、2009013113-Management.txtになります。表6-4は、管理レポートの内容を示しています。

表6-4 管理レポートの内容

列	型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
Refresh Policy	String	現行で設定されているリフレッシュ・ポリシーで、これを使用して、リモート・モデルのデータのリフレッシュ方法を決定します。
Refresh Time	Date	このモデルが、対応するメンバーから前回取得されたときのタイムスタンプ。ローカル・サーバーの場合はローカル時間になります。
Refresh Excess Count	Long	MBeanサーバーによって情報が予測的にリフレッシュされ、その情報がアクセスされなかった回数。
Refresh Count	Long	統計が最後にリセットされてから取得されたスナップショットの合計数。
Refresh Prediction Count	Long	MBeanサーバーによって予測的なアルゴリズムが使用され、MBean情報がリフレッシュされた回数。
Refresh Timeout Count	Long	この管理メンバーがリモートMBean属性のリフレッシュ試行中にタイムアウトした回数。

6.5 メモリー・ステータス・レポートについて

メモリー・ステータス・レポートは、レポート・バッチの一部として実行する必要があります。この値は、各メンバーおよびグリッド全体のメモリー消費量の把握に役立ちます。データを含めるには、プラットフォームMBean情報を公開するようにクラスタ・メンバーを構成する必要があります。メモリー・ステータス・ファイルはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-memory-status.txtが付きます。たとえば、2009年1月31日午後3時に作成されたファイルの名前は、2009013115-memory-status.txtになります。表6-5は、メモリー・ステータス・レポートの内容を示しています。

表6-5 メモリー・ステータス・レポートの内容

列	データ型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
JVM Uptime	Long	JVMの開始以降の経過時間。
Node Id	Long	メモリー統計の対象メンバー。
Gc Name	String	ガベージ・コレクタ情報の名前。
CollectionCount	Long	コンピュータの起動後に発生したガベージ・コレクションの回数。
Delta Collection Count	Long	前回のレポート実行以降に発生したガベージ・コレクションの数。
CollectTime	Long	JVMが起動後にガベージ・コレクションに費やした時間(ミリ秒)。
Delta Collect Time	Long	前回のレポート実行以降にJVMがガベージ・コレクションに費やした時間(ミリ秒)。
Last GC Start Time	Long	最後のガベージ・コレクションの開始時刻。
Last GC Duration Millis	Long	最後のガベージ・コレクションの合計時間。
Last GC Stop Time	Long	最後のガベージ・コレクションの終了時刻。
Heap Committed	Long	レポート実行時点におけるコミット済ヒープ・バイト数。
Heap Init	Long	レポート実行時点における初期化済ヒープ・バイト数。
Heap Max	Long	JVMが起動後に使用した最大バイト数。
Heap Used	Long	レポート実行時点でJVMが使用していたバイト数。

6.6 ネットワーク・ヘルス詳細レポートについて

ネットワーク・ヘルス・レポートは、ネットワーク通信の状態確認に役立つメンバー・レベルの詳細情報をサポートしています。ネットワーク・ヘルス詳細ファイルはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-network-health-detail.txtが付きます。たとえば、2009年1月31日午後2時に作成されたファイルの名前は、2009013114-network-health.txtになります。表6-6は、ネットワーク・ヘルス詳細レポートの内容を示しています。

表6-6 ネットワーク・ヘルス詳細レポートの内容

列	データ型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
RefreshTime	Date	管理情報が、対応するノードから前回取得されたときのシステム時刻。ローカル・サーバーはローカル時間を表示します。
Node Id	Long	ネットワーク統計の対象メンバー。
Tx Success	Double	メンバーにおけるパブリッシャの成功率。この値が、ネットワーク・ヘルス・ファイルのバッチに示される「Min Node Tx Success」値の2%から3%以内にあり、「Grid Tx Success」値よりも10%未満の場合、対象メンバーとクラスタとの間に通信上の問題がある可能性があります。この問題の要因としては、CPUまたはネットワーク帯域幅の制約、あるいはネットワークの長い待機時間などが考えられます。
RX Success	Double	メンバーにおける受信側の成功率。この値が、ネットワーク・ヘルス・ファイルのバッチに示される「Min Node Rx Success」値の2%から3%以内にあり、「Grid Tx Success」値よりも10%未満の場合、対象メンバーとクラスタとの間に通信上の問題がある可能性があります。この問題の要因としては、CPUまたはネットワーク帯域幅の制約、あるいはネットワークの長い待機時間などが考えられます。
Packets Sent	Double	メンバーから送信されたネットワーク・パケットの総数。
Current Packets Sent	Long	前回のレポート実行以降にメンバーから送信されたパケットの数。
Packets Resent	Long	メンバーから再送信されたネットワーク・パケットの総数。パケットの受信側が無効なパケットを受信した場合、または適切な時間内に確認パケットが送信されなかった場合、パケットは再送信されます。
Current Packet Resent	Long	前回のレポート実行以降にメンバーから再送信されたネットワーク・パケットの数。
PacketsRepeated	Long	1回以上受信したパケットの総数。
Current Packets Repeated	Long	前回のレポート実行以降に2回以上受信したパケットの数。
Packets Received	Long	メンバーが受信したパケットの総数。
Current Packets Received	Long	前回のレポート実行以降にメンバーが受信したパケットの総数。

6.7 ネットワーク・ヘルス・レポートについて

ネットワーク・ヘルス・レポートには、ネットワーク通信の状態を確認するための主要な集計情報が含まれます。ネットワーク・ヘルス・ファイルはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-network-health.txtが付きます。たとえば、2009年1月31日午後1時に作成されたファイルの名前は、2009013113-network-health.txtになります。表6-7は、ネットワーク・ヘルス・レポートの内容を示しています。

表6-7 ネットワーク・ヘルス・レポートの内容

列	型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
Min Node Rx Success	Double	クラスタ内のメンバーにおける受信側の最小成功率。この値が「Grid Rx Success」率を大幅に下回った(10%)場合。ネットワーク・ヘルス・ディテールを使用したより詳細な分析が必要になります。
Grid Rx Success	Double	グリッド全体における受信側の成功率。この値が90%より低い場合。ネットワーク・ヘルス・ディテールを使用したより詳細な分析が必要になります。
Min Node Tx Success	Double	クラスタ内のメンバーにおけるパブリッシャの最小成功率。この値が「Grid Rx Success」率を大幅に下回った(10%)場合。ネットワーク・ヘルス・ディテールを使用したより詳細な分析が必要になります。
Grid TX Success	Double	グリッド全体におけるパブリッシャの成功率。この値が90%より低い場合。ネットワーク・ヘルス・ディテールを使用したより詳細な分析が必要になります。

6.8 ノード・リスト・レポートについて

ノード識別子(nodeId)は一時的であるという性質をもつため、レポータは、メンバーのリストとユーザー定義のメンバーの識別情報をログに出力します。『Oracle Coherence開発者ガイド』のmember-identityに関する項を参照してください。ノード・リスト・ファイルはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-nodes.txtが付きます。たとえば、2009年1月31日午前1時に作成されたファイルの名前は、2009013101-nodes.txtになります。表6-8は、ノード・リスト・レポートの内容を示しています。

表6-8 ノード・リスト・レポートの内容

列	データ型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
Node Id	String	数値のメンバー識別子。
Unicast Address	String	メンバーのユニキャスト・アドレス。
Member Name	String	メンバー名。
Process Name	String	メンバーのプロセス名。
Role Name	String	メンバーのロール名。
Machine Name	String	メンバーのコンピュータ名。
Rack Name	String	メンバーのラック名。
Site Name	String	メンバーのサイト名。
Refresh Time	Date/Time	情報がリモート・メンバーからリフレッシュされた時刻。この時刻がバッチに出力された他の行のリフレッシュ時刻と異なる場合、このメンバーは適時に応答しなかったことになります。この現象は一般に、ガベージ・コレクションを実行しているメンバーで発生します。リフレッシュ日付が古いメンバーに関する情報は信頼できません。

6.9 プロキシ・レポートについて

プロキシ・ファイルには、プロキシ・サーバーに関する情報およびクライアントに転送された情報が格納されます。プロキシ・ファイルはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-report-proxy.txtが付きます。たとえば、2009年1月31日午前1時に作成されたファイルの名前は、2009013101-report-proxy.txtになります。表6-9は、プロキシ・レポートの内容を示しています。

表6-9 プロキシ・レポートの内容

列	型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
Node Id	String	数値のメンバー識別子。
Service Name	String	プロキシ・サービスの名前。
HostIp	String	プロキシ・サービスのIPアドレスおよびポート。
Connection Count	Long	プロキシ・サービスの現在の接続数。
Outgoing Byte Backlog	Long	プロキシ・サービスの送信キューに入れられているバイト数。
Outgoing Message Backlog	Long	プロキシ・サービスの送信キューに入れられているメッセージ数。
Bytes Sent	Long	前回のレポート実行以降にプロキシ・サービスから送信されたバイト数。
Bytes Received	Long	前回のレポート実行以降にプロキシ・サービスが受信したバイト数。
Messages Sent	Long	前回のレポート実行以降にプロキシ・サービスから送信されたメッセージ数。
Messages Received	Long	前回のレポート実行以降にプロキシ・サービスが受信したメッセージ数。

6.10 RAMジャーナル・レポートについて

RAMジャーナル・レポートには、RAMメモリーにデータがどれくらい効率的に保存されているかを確認するために役立つ統計が表示されます。このレポートはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付と時間、末尾には-ramjournal.txtが付きます。たとえば、2010年1月31日午後1時に作成されたファイルの名前は、2010013113-ramjournal.txtになります。表6-10は、キャッシュの使用レポートの内容を示しています。

表6-10 RAMジャーナル・レポートの内容

列	型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
Node ID	Long	フラッシュ・ジャーナルの統計の対象メンバー。
FileCount	Integer	現在使用中のジャーナル・ファイルの数。
BinaryStoreCount	Integer	このジャーナルを使用しているアクティブな`JournalBinaryStore`オブジェクトの数。
TotalDataSize	Long	このジャーナルに現在保存されているバイト単位のデータ量。
TotalFileSize	Long	このジャーナルのすべてのジャーナル・ファイルの合計サイズ。

6.11 サービス・レポートについて

サービス・レポートは、処理済のリクエスト、失敗したリクエスト、未処理のリクエスト、処理済のタスク、失敗したタスクおよび未処理のタスクに関する情報を提供します。Request CountおよびTask Countは、サービスのパフォーマンスとスループットを確認する場合に有用です。RequestPendingCountおよびTask Backlogは、容量の問題やブロックされたプロセスの特定に有用です。Task Hung Count、Task Timeout Count、Thread Abandoned CountおよびRequest Timeout Countは、システムで発生した実行の失敗数を示します。表6-11は、サービス・レポートの内容を示しています。

表6-11 サービス・レポートの内容

列	データ型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートが実行されたシステム時間。
Service	String	サービス名。
Node Id	String	数値のメンバー識別子。
Refresh Time	Date	サービス情報がリモート・メンバーから更新されたシステム時間。
Request Count	Long	前回のレポート実行以降のリクエスト数。
RequestPendingCount	Long	レポート実行時点における未処理のリクエスト数。
RequestPendingDuration	Long	レポート実行時点における未処理リクエストの待機時間。
Request Timeout Count	Long	前回のレポート実行以降のリクエストのタイムアウト回数。
Task Count	Long	前回のレポート実行以降に実行されたタスクの数。
Task Backlog	Long	レポート実行時点における未処理のタスク数。
Task Timeout Count	Long	前回のレポート実行以降のタスクのタイムアウト回数。
Task Hung Count	Long	前回のレポート実行以降にハングしたタスクの数。
Thread Abandoned Count	Long	前回のレポート実行以降に破棄されたスレッドの数。