6 レポート内容の分析

この章では、Oracle Coherenceに含まれる事前定義済レポートについて説明します。開発者およびシステム管理者は、レポートを使用して操作統計をモニターおよび分析したり、潜在的な問題のトラブルシューティングを行います。Oracle Coherence*Web固有のレポートについては、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。

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

• キャッシュ・サイズ・レポートの理解

• キャッシュの使用レポートの理解

• フラッシュ・ジャーナル・レポートの理解

• JCache構成レポートの理解

• JCache統計レポートの理解

• 管理レポートの理解

• メモリー・ステータス・レポートの理解

• ネットワーク・ヘルス詳細レポートの理解

• ネットワーク・ヘルス・レポートの理解

• ノード・リスト・レポートの理解

• プロキシ・レポートの理解

• RAMジャーナル・レポートの理解

• サービス・レポートの理解

6.1 キャッシュ・サイズ・レポートの理解

キャッシュ・サイズ・レポートは、キャッシュ内にあるオブジェクトの数とサイズに基づいてキャッシュ・サイズを示します。このサイズは、バックアップ・コピー、索引やオーバーヘッドを考慮に入れていません。<local-scheme>の<unit-calculator>サブ要素をBINARYに設定したキャッシュのサイズが報告されます。このキャッシュ・サイズ・レポートの名前は、timestamp-cache-size.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2009013101-cache-size.txtは、2009年1月31日の午前1時のキャッシュ・サイズ・レポートを表します。表6-1は、キャッシュ・サイズ・レポートの内容を示します。

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

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

6.2 キャッシュの使用レポートの理解

キャッシュの使用レポートは、キャッシュの使用(get、put、エビクションなど)に関する情報を提供します。このキャッシュの使用レポートの名前は、timestamp-cache-usage.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2010013113-cache-usage.txtは、2010年1月31日の午後1時のキャッシュ使用レポートを表します。表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 Millis	Double	前回レポートがリフレッシュされてからクラスタ全体でput()呼出しごとにかかった合計時間(ミリ秒)
Total Gets	Double	前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してgetが実行された合計回数
Total Gets Millis	Double	前回レポートがリフレッシュされてからクラスタ全体でget()呼出しごとにかかった合計時間(ミリ秒)
Total Hits	Double	前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してアクセスした合計回数
Total Hits Millis	Double	前回レポートがリフレッシュされてからクラスタ全体でヒットだったget()呼出しごとにかかった合計時間(ミリ秒)
Total Misses	Double	前回レポートがリフレッシュされてからクラスタ全体でのキャッシュに対するミスの合計数
Total Misses Millis	Double	前回レポートがリフレッシュされてからクラスタ全体でミスだったget()呼出しごとにかかった合計時間(ミリ秒)
Total Writes	Double	前回レポートがリフレッシュされてからクラスタ全体でキャッシュについて記憶域への書込みが実行された合計回数
Total Write Millis	Double	前回レポートがリフレッシュされてからクラスタ全体で記憶域への書込み操作にかかった合計時間(ミリ秒)
Total Reads	Double	前回レポートがリフレッシュされてからクラスタ全体でキャッシュのキャッシュ・ストアから読取りが実行された合計回数
Total Read Millis	Double	前回レポートが実行されてからクラスタ全体でキャッシュのキャッシュ・ストアの読取りにかかった合計時間(ミリ秒)
Total Failures	Long	前回レポートがリフレッシュされてからクラスタ全体でキャッシュについて障害が発生した合計回数
Total Queue	Long	クラスタ全体のキュー・リンク・サイズの合計
Evictions	Long	前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してエビクションが実行された合計回数
Cache Prunes	Long	前回レポートがリフレッシュされてからクラスタ全体でキャッシュに対してプルーニングが実行された合計回数
Cache Prunes Millis	Long	前回レポートがリフレッシュされてからクラスタ全体でプルーニング操作にかかった合計時間(ミリ秒)

6.3 フラッシュ・ジャーナル・レポートの理解

フラッシュ・ジャーナル・レポートには、フラッシュ・メモリーにデータがどれくらい効率的に保存されているかを確認するために役立つ統計が表示されます。このフラッシュ・ジャーナル・レポートの名前はtimestamp-flashjournal.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2010013113-flashjournal.txtは、2010年1月31日の午後1時のフラッシュ・ジャーナル・レポートを表します。表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 JCache構成レポートの理解

JCache構成レポートには、JCacheキャッシュで設定された構成オプションが表示されます。Cacheキャッシュは、キャッシュが作成される際にJCache APIを使用してプログラムから構成されます。このレポートの名前はtimestamp-jcache-configuration.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2009013113-jcache-configuration.txtは、2009年1月31日の午後1時の管理レポートを表します。表6-4は、JCache構成レポートの内容を示します。

表6-4 JCache構成レポートの内容

列	データ型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
ReportTime	Date	レポートの各リフレッシュのタイムスタンプ
CacheManager	String	キャッシュを作成したJCache CacheManagerインスタンス。Coherenceキャッシュ・マネージャは、JCacheNamespaceハンドラ・クラスを定義するキャッシュ構成ファイルによって一意に識別され、スコープ設定されます。
Cache	String	キャッシュの名前
KeyType	String	キャッシュが必要とするキーの型です。
ValueType	String	キャッシュが必要とする値の型です。
ManagementEnabled	Boolean	キャッシュの管理が有効化されているかどうかを示します
StatisticsEnabled	Boolean	キャッシュのパフォーマンス統計が収集されているかどうかを示します
ReadThrough	Boolean	キャッシュ操作がリードスルー・モードかどうかを示します
WriteThrough	Boolean	キャッシュ操作がライトスルー・モードかどうかを示します
StoreByValue	Boolean	キャッシュが値による格納または参照による格納のどちらのセマンティクスを使用しているかを示します。trueは、キーと値は値によって格納されることを示します。falseは、キーと値は参照によって格納されることを示します。

6.5 JCache統計レポートの理解

JCache統計レポートには、JCacheキャッシュがどれくらい効率的に実行されているかを評価するのに使用される情報が含まれます。このレポートの名前はtimestamp-jcache-statistics.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2009013113-jcache-statistics.txtは、2009年1月31日の午後1時の管理レポートを表します。表6-5は、JCache統計レポートの内容を示します。

表6-5 JCache統計レポートの内容

列	データ型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
ReportTime	Date	レポートの各リフレッシュのタイムスタンプ
CacheManager	String	キャッシュを作成したJCache CacheManagerインスタンス。Coherenceキャッシュ・マネージャは、JCacheNamespaceハンドラ・クラスを定義するキャッシュ構成ファイルによって一意に識別され、スコープ設定されます。
Cache	String	キャッシュの名前
CacheGets	Long	get操作の総数です。この値はヒットとミスの合計に等しく、キーの存在チェック操作は含みません。
CachePuts	Long	既存のエントリの置換操作を含むput操作の総数です
CacheRemovals	Long	remove操作の総数です。スペースを開放するためにキャッシュによって開始されるエビクションは含みません。
CacheHits	Long	成功したget操作の回数です。
CacheMisses	Long	成功しなかったget操作の回数です。
CacheEvictions	Long	キャッシュからのエビクションの総数です。エビクションは、スペースを開放するため、キャッシュによって開始されます。エビクションは、remove操作とはみなされません。 注意: この属性は、Coherence JCacheプロバイダでは実装されていません。
AverageGetTime	Float	get操作を行う平均時間です。リードスルー・キャッシュの場合、キャッシュ・ミスによるエントリのロードに必要な時間は含まれません。
AveragePutTime	Float	put操作を行う平均時間です。
AverageRemoveTime	Float	remove操作を行う平均時間です。
CacheHitPercentage	Float	エントリを返したキャッシュ・リクエストの割合です。この割合は、キャッシュ・ヒットをキャッシュのget操作で割って計算され、10進値として報告されます。
CacheMissPercentage	Float	エントリを返さなかったキャッシュ・リクエストの割合です。この割合は、キャッシュ・ミスをキャッシュのget操作で割って計算され、10進値として報告されます。

6.6 管理レポートの理解

管理レポートには、管理フレームワークがすべてのMBeanに対してタイムリな管理データを表示しているかどうかを確認するためのリフレッシュ統計があります。この管理レポートの名前はtimestamp-management.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2009013113-Management.txtは、2009年1月31日の午後1時の管理レポートを表します。表6-6は、管理レポートの内容を示します。

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

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

6.7 メモリー・ステータス・レポートの理解

メモリー・ステータス・レポートには、各メンバーおよびグリッド全体のメモリー消費を把握するために役立つ統計が含まれます。メモリー・ステータス・レポートは、レポート・グループの一部として実行する必要があります。メモリー・ステータス・レポートは、プラットフォームMBeanの情報に依存しています。「MBeanのフィルタリング」を参照してください。このメモリー・ステータス・レポートの名前はtimestamp-memory-status.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2009013115-memory-status.txtは、2009年1月31日の午後3時のメモリー・ステータス・レポートを表します。表6-7は、メモリー・ステータス・レポートの内容を示します。

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

列	データ型	説明
Batch Counter	Long	関連ファイルの情報の統合に役立つ順次カウンタ。この値は、レポータが再起動され、メンバー全体での一貫性がない場合にリセットされます。しかし、ファイルの統合を試みる際には役立ちます。
Report Time	Date	レポートの各リフレッシュのタイムスタンプ
JVM Uptime	Long	前回のJVM起動からの経過時間
Node Id	Long	メモリー統計の対象メンバー
Gc Name	String	ガベージ・コレクタの名前
CollectionCount	Long	前回のJVM起動以降のガベージ・コレクションの回数
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.8 ネットワーク・ヘルス詳細レポートの理解

ネットワーク・ヘルス詳細レポートには、ネットワーク通信の状態を確認するためのメンバー・レベルの詳細が含まれます。このネットワーク・ヘルス詳細レポートの名前はtimestamp-network-health-detail.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2009013114-network-health-detail.txtは、2009年1月31日の午後2時のネットワーク・ヘルス詳細レポートを表します。表6-8は、ネットワーク・ヘルス詳細レポートの内容を示します。

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

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

6.9 ネットワーク・ヘルス・レポートの理解

ネットワーク・ヘルス・レポートには、ネットワーク通信の状態を確認するために役立つ主要な集計情報が含まれます。このネットワーク・ヘルス・レポートの名前はtimestamp-network-health.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2009013113-network-health.txtは、2009年1月31日の午後1時のネットワーク・ヘルス・レポートを表します。表6-9は、ネットワーク・ヘルス・レポートの内容を示します。

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

列	データ型	説明
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.10 ノード・リスト・レポートの理解

ノード・リスト・レポートは、クラスタ・メンバーの識別に役立つ情報を提供します。ノード識別子(nodeId)は一時的であるという性質をもつため、レポータは、メンバーのリストとユーザー定義のメンバーの識別情報をログに出力します。『Oracle Coherenceでのアプリケーションの開発』の<member-identity要素を参照してください。このノード・リスト・レポートの名前はtimestamp-nodes.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2009013101-nodes.txtは、2009年1月31日の午前1時のノード・リスト・レポートを表します。表6-10は、ノード・リスト・レポートの内容を示します。

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

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

6.11 プロキシ・レポートの理解

プロキシ・レポートには、プロキシ・サーバーに関する情報およびクライアントに転送された情報が含まれます。このプロキシ・レポートの名前はtimestamp-network-report-proxy.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2009013101-report-proxy.txtは、2009年1月31日の午前1時のプロキシ・レポートを表します。表6-11は、プロキシ・レポートの内容を示します。

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

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

6.12 RAMジャーナル・レポートの理解

RAMジャーナル・レポートには、RAMメモリーにデータがどれくらい効率的に保存されているかを確認するために役立つ統計が表示されます。このRAMジャーナル・レポートの名前はtimestamp-ramjournal.txtです。ここで、タイムスタンプはYYYYMMDDHH形式になります。たとえば、ファイル2010013113-ramjournal.txtは、2010年1月31日の午後1時のRAMジャーナル・レポートを表します。表6-12は、RAMジャーナル・レポートの内容を示します。

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

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

6.13 サービス・レポートの理解

サービス・レポートには、サービスのヘルスおよびパフォーマンスをモニタリングするための情報が含まれます。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-13は、サービス・レポートの内容を示します。

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

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