This chapter includes the following sections:
The cache size report indicates the size of a cache based on the number and size of the objects in the cache. The size does not include backup copies, indexes, or overhead. The size is reported for caches that set the <unit-calculator>
subelement of <local-scheme>
to BINARY
. The name of the cache size report is timestamp
-cache-size.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013101-cache-size.txt
represents a cache size report for January 31, 2009 at 1:00 a.m. Table 6-1 describes the contents of a cache size report.
Table 6-1 Contents of the Cache Size Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
The name of the cache service |
|
|
The name of the cache |
|
|
The number of objects in the cache |
|
|
The number of bytes consumed by the objects in the cache |
|
|
The number of Megabytes (MB) consumed by the objects in the cache |
|
|
The average amount of memory consumed by each object |
The cache usage report provides information about cache usage (gets, puts, evictions, and so on). The name of the cache usage report is timestamp
-cache-usage.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2010013113-cache-usage.txt
represents a cache usage report for January 31, 2010 at 1:00 p.m. Table 6-2 describes the contents of the cache usage report.
Table 6-2 Contents of the Cache Usage Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts, and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The name of the cache service |
|
|
The name of the cache |
|
|
Whether the cache resides in the front tier (local cache) or back tier (remote cache). The value is either |
|
|
The total number of puts for the cache across the cluster since the last report refresh |
|
|
The total number of milliseconds spent per |
|
|
The total number of gets for the cache across the cluster since the last report refresh |
|
|
The total number of milliseconds spent per |
|
|
The total number of visits for the cache across the cluster since the last report refresh |
|
|
The total number of milliseconds spent per |
|
|
The total number of misses for the cache across the cluster since the last report refresh |
|
|
The total number of milliseconds spent per |
|
|
The total number of storage writes for the cache across the cluster since the last report refresh |
|
|
The total number of milliseconds spent in storage write operations across the cluster since the last report refresh |
|
|
The total number of reads from a cache store for the cache across the cluster since the last report refresh |
|
|
The total number of milliseconds spent on cache store reads for the cache across the cluster since the last time the report executed |
|
|
The total number of failures for the cache across the cluster since the last report refresh |
|
|
The sum of the queue link sizes across the cluster |
|
|
The total number of evictions for the cache across the cluster since the last report refresh |
|
|
The total number of prunes for the cache across the cluster since the last report refresh |
|
|
The total number of milliseconds spent in the prune operation across the cluster since the last report refresh |
The federation destination report indicates out-going replication statistics from the perspective of a federation participant who receives replicated data. The name of the federation destination report is timestamp
-federation-destination.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013101-federation-destination.txt
represents a report for January 31, 2009 at 1:00 a.m. Table 6-3 describes the contents of a federation destination report.
Table 6-3 Contents of the Federation Destination Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts, and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The member for the federation statistics |
|
|
The name of the sender |
|
|
The state of the participant. One of: |
|
|
The status of the participant. Statuses are:
|
|
|
The current utilized bandwidth in Megabits per second for sending replicate message |
|
|
The total number of bytes that were sent |
|
|
The total number of cache entries that were sent |
|
|
The total number of journal records that were sent. A journal record can consist of multiple cache entries that are part of the same transaction |
|
|
The total number of replication messages that were sent. A replication message can contain multiple journal records. |
|
|
The total number of un-acknowledged replication messages |
|
|
The 90-percentile value of the time (in milliseconds) the journal records are in the cache waiting to be replicated |
|
|
The 90-percentile value of the time (in milliseconds) taken by transmission of replication messages and the corresponding acknowledge messages over the network |
|
|
The 90-percentile value of the time (in milliseconds) it took to apply the replication messages on the destination |
|
|
The bytes sent per second |
|
|
The messages sent per second |
|
|
The maximum bandwidth in megabits per second for sending replicate messages. A value of |
|
|
An error description. A value is only returned if the sender is in an |
|
|
The send timeout that is configured for the participant |
|
|
The location metadata that is configured for the participant |
The federation origin report indicates in-coming replication statistics from the perspective of a federation participant who sends replicated data. The name of the federation origin report is timestamp
-federation-origin.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013101-federation-origin.txt
represents a report for January 31, 2009 at 1:00 a.m. Table 6-4 describes the contents of a federation origin report.
Table 6-4 Contents of the Federation Origin Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts, and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The member for the federation statistics |
|
|
The total number of bytes that were received |
|
|
The total number of journal records that were received. A journal record could consist of multiple cache entries that are part of the same transaction |
|
|
The total number of cache entries that were received |
|
|
The total number of replication messages that were received. A replication message could contain multiple journal records |
|
|
The total number of un-acknowledged replication messages |
|
|
The 90-percentile value of the time (in milliseconds) it took to apply the replication messages on the destination. |
|
|
The 90-percentile value of the time (in milliseconds) the journal records are in the cache waiting to be replicated |
|
|
The bytes received per second |
|
|
The messages received per second |
The cache size report indicates the status for a federation participant. The name of the federation status report is timestamp
-federation-status.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013101-federation-status.txt
represents a cache size report for January 31, 2009 at 1:00 a.m. Table 6-5 describes the contents of a federation status report.
Table 6-5 Contents of the Federation Status Report
Column | Data Type | Description |
---|---|---|
|
|
The member for the federation statistics |
|
|
The name of the sender |
|
|
The state of the participant. One of: |
|
|
An error description. A value is only returned if the sender is in an |
The flash journal report displays statistics to help determine how well data is being stored to flash memory. The name of the flash journal report is timestamp
-flashjournal.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2010013113-flashjournal.txt
represents a flash journal report for January 31, 2010 at 1:00 p.m. Table 6-6 describes the contents of the flash journal report.
Table 6-6 Contents of the Flash Journal Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The member for the flash journal statistics |
|
|
The number of journal files that are currently in use |
|
|
The number of active |
|
|
The amount of data, in bytes, that is currently stored for this journal |
|
|
The total size of all journal files for this journal |
|
|
The number of serialized values that have yet to be stored in the journal |
|
|
The maximum size, in bytes, of the backlog. The backlog is the amount of serialized values that have yet to be stored in the journal. Client threads are blocked if this limit is exceeded and remain blocked until the backlog recedes below this limit. |
|
|
The total size, in bytes, of all available buffers in the pool |
The JCache configuration report shows what configuration options have been set on a JCache cache. JCache caches are configured programmatically using the JCache API when the cache is created. The name of the report is timestamp
-jcache-configuration.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013113-jcache-configuration.txt
represents a management report for January 31, 2009 at 1:00 p.m. Table 6-7 describes the contents of the JCache configuration report.
Table 6-7 Contents of the JCache Configuration Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The JCache |
|
|
The name of the cache |
|
|
The required key type for the cache. |
|
|
The required value type for the cache. |
|
|
Specifies whether management is enabled for the cache |
|
|
Specifies whether performance statistics are being collected for the cache |
|
|
Specifies whether the cache operates in read-through mode |
|
|
Specifies whether the cache operates in write-through mode |
|
|
Specifies whether the cache uses store-by-value or store by-reference semantics. A value of |
The JCache statistic report contains information that is used to evaluate how well a JCache cache is performing. The name of the report is timestamp
-jcache-statistics.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013113-jcache-statistics.txt
represents a management report for January 31, 2009 at 1:00 p.m. Table 6-8 describes the contents of the JCache statistics report.
Table 6-8 Contents of the JCache Statistics Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The JCache |
|
|
The name of the cache |
|
|
The total number of |
|
|
The total number of put operations including operations that replace and existing entry |
|
|
The total number of |
|
|
The number of successful |
|
|
The number of unsuccessful |
|
|
The total number of evictions from the cache. An eviction is initiated by the cache to free up space. An eviction is not considered a Note: This attribute is not implemented by the Coherence JCache provider. |
|
|
The average time to perform |
|
|
The average time to perform |
|
|
The average time to perform |
|
|
The percentage of cache requests that return an entry. The percentage is reported as a decimal value and is calculated using the value of cache hits divided by cache |
|
|
The percentage of cache requests that do not return an entry. The percentage is reported as a decimal value and is calculated using the value of cache misses divided by cache |
The management report contains refresh statistics to help determine if the management framework is providing a timely view of management data for all MBeans. The name of the management report is timestamp
-management.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013113-Management.txt
represents a management report for January 31, 2009 at 1:00 p.m. Table 6-9 describes the contents of the management report.
Table 6-9 Contents of the Management Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The refresh policy that is currently set. The policy determines how to refresh data for remote models. |
|
|
The timestamp when this model was last retrieved from a corresponding member. For local servers it is the local time. |
|
|
The number of times that the MBean server predictively refreshed information and the information was not accessed |
|
|
The total number of snapshots retrieved since the statistics were last reset |
|
|
The number of times that the MBean server used a predictive algorithm to refresh MBean information |
|
|
The number of times that this management member has timed out while attempting to refresh remote MBean attributes |
The memory status report contains statistics to help understand memory consumption on each member and across the grid. A memory status report must be run as part of a report group. The memory status report relies on platform MBean information. See "Filtering MBeans". The name of the memory status report is timestamp
-memory-status.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013115-memory-status.txt
represents a memory status report for January 31, 2009 at 3:00 p.m. Table 6-10 describes the contents of the memory status report.
Table 6-10 Contents of the Memory Status Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The amount of time since the last JVM start |
|
|
The member for the memory statistics |
|
|
The name of the garbage collector |
|
|
The number of garbage collections since the last JVM start |
|
|
The number of garbage collections since the last report refresh |
|
|
The number of milliseconds that the JVM has spent on garbage collection since the start of the JVM |
|
|
The number of milliseconds that the JVM has spent on garbage collection since the last report refresh |
|
|
The start time of the last garbage collection |
|
|
The total amount of time of the last garbage collection |
|
|
The stop time of the last garbage collection |
|
|
The number of heap bytes committed at the time the report ran |
|
|
The number of heap bytes initialized at the time the report ran |
|
|
The maximum number of bytes used by the JVM since its start |
|
|
The bytes used by the JVM at the time the report ran |
The network health detail report contains member-level details to help determine the health of network communications. The name of the network health detail report is timestamp
-network-health-detail.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013114-network-health-detail.txt
represents a network health detail report for January 31, 2009 at 2:00 p.m. Table 6-11 describes the contents of the network health detail report.
Table 6-11 Contents of the Network Health Detail Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The system time when management information was last retrieved from a corresponding node. Local servers display the local time. |
|
|
The member for the network statistics. |
|
|
The publisher success rate for the member. If this value is within 2% to 3% of the |
|
|
The receiver success rate for the member. If this value is within 2% to 3% of the |
|
|
The total number of network packets sent by the member |
|
|
The number of packets sent by the member since the last report refresh |
|
|
The total number of network packets re-sent by the member. Packets are re-sent when the receiver of the packet receives an invalid packet or when an acknowledge packet is not sent within the appropriate amount of time. |
|
|
The number of network packets re-sent by the member since the last report refresh |
|
|
The total number of packets received multiple times |
|
|
The number of packets received multiple times since the last report refresh |
|
|
The total number of packets received by the member |
|
|
The total number of packets received by the member since the last report refresh |
The network health report contains the primary aggregates to help determine the health of the network communications. The name of the network health report is timestamp
-network-health.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013113-network-health.txt
represents a network health report for January 31, 2009 at 1:00 p.m. Table 6-12 describes the contents of the network health report.
Table 6-12 Contents of the Network Health Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The minimum receiver success rate for a member in the cluster. If this value is considerably less (10%) than the |
|
|
The receiver success rate for the grid as a whole. If this value is below 90%, analyze the network health detail report. |
|
|
The minimum publisher success rate for a member in the cluster. If this value is considerably less (10%) than the |
|
|
The publisher success rate for the grid as a whole. If this value is below 90%, analyze the network health detail report. |
The node list report provides information to help identify a cluster member. Due to the transient nature of the node identifier (nodeId
), the reporter logs out a list of members and user-defined member identity information. See the <member-identity>
element in the Developing Applications with Oracle Coherence. The name of the nodes list report is timestamp
-nodes.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013101-nodes.txt
represents a node list report for January 31, 2009 at 1:00 a.m. Table 6-13 describes the contents of the node list report.
Table 6-13 Contents of the Node List Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The time at which the information was refreshed from a remote member. If the time is different than the refresh time on other rows in the batch, the member did not respond in a timely matter. This is often caused by a member performing a garbage collection. Any information regarding a member with an old refresh date is questionable. |
|
|
The numeric member identifier |
|
|
The Unicast address for the member |
|
|
The member name |
|
|
The process name for the member |
|
|
The role name for the member |
|
|
The computer name for the member |
|
|
The rack name for the member |
|
|
The site name for the member |
The persistence report provides detailed information about how cache persistence is performing for a particular service and node. The name of the persistence detail report is timestamp
-persistence-detail.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013101-persistence-detail.txt
represents a persistence detail report for January 31, 2009 at 1:00 a.m. Table 6-14 describes the contents of the persistence detail report.
Table 6-14 Contents of the Persistence Detail Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The name of the partitioned cache service |
|
|
The current persistence mode for this service:
|
|
|
The member for the persistence statistics |
|
|
The average latency (in milliseconds) added to a mutating cache operation by active persistence operations |
|
|
The maximum latency (in milliseconds) added to a mutating cache operation by an active persistence operation. |
|
|
The amount of space (in bytes) that is used by active persistence |
|
|
The total size (in bytes) of the file system for use by active persistence |
|
|
The remaining space (in bytes) available on the file system for active persistence |
|
|
The total size (in bytes) of the file system to store snapshots |
|
|
The remaining space (in bytes) available on the file system to store snapshots |
The persistence report provides information about how cache persistence is performing for a particular service. The name of the persistence report is timestamp
-persistence.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013101-persistence.txt
represents a persistence report for January 31, 2009 at 1:00 a.m. Table 6-15 describes the contents of the persistence report.
Table 6-15 Contents of the Persistence Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The name of the partitioned cache service |
|
|
The current persistence mode for this service:
|
|
|
The amount of space (in bytes) that is used by active persistence |
|
|
The average latency for all nodes (in milliseconds) added to a mutating cache operation by active persistence operations |
|
|
The maximum latency for all nodes (in milliseconds) added to a mutating cache operation by an active persistence operation. |
The proxy report provides information about proxy servers and the information being transferred to clients. The name of the proxy report is timestamp
-network-report-proxy.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2009013101-report-proxy.txt
represents a proxy report for January 31, 2009 at 1:00 a.m. Table 6-16 describes the contents of the proxy report.
Table 6-16 Contents of the Proxy Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The timestamp when this model was last retrieved from a corresponding member. For local servers it is the local time. |
|
|
The name of the proxy service |
|
|
The IP Address and Port of the proxy service |
|
|
The numeric member identifier |
|
|
The current number of connections to the proxy service |
|
|
The number of bytes queued to be sent by the proxy service |
|
|
The number of messages queued by the proxy service |
|
|
The number of bytes sent by the proxy service since the last report refresh |
|
|
The number of bytes received by the proxy service since the last report refresh |
|
|
The number of messages sent by the proxy service since the last report refresh |
|
|
The number of messages received by the proxy service since the last report refresh |
The ram journal report displays statistics that are used to determine how well data is being stored to RAM memory. The name of the ram journal report is timestamp
-ramjournal.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2010013113-ramjournal.txt
represents a ram journal report for January 31, 2010 at 1:00 p.m. Table 6-17 describes the contents of the ram journal report.
Table 6-17 Contents of the Ram Journal Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The member for the RAM journal statistics |
|
|
The number of journal files that are currently in use |
|
|
The number of active |
|
|
The amount of data, in bytes, that is currently stored for this journal |
|
|
The total size of all journal files for this journal |
The service report provides information for monitoring the health and performance of a service. The Request Count
and Task Count
values help to determine the performance and throughput of the service. The RequestPendingCount
and Task Backlog
values help to identify capacity issues or blocked processes. The Task Hung Count
, Task Timeout Count
, Thread Abandoned Count
, and Request Timeout Count
values represent the number of unsuccessful executions that have occurred in the system. The name of the service report is timestamp
-service.txt
where the timestamp is in YYYYMMDDHH
format. For example, a file named 2010013113-service.txt
represents a service report for January 31, 2010 at 1:00 p.m. Table 6-18 describes the contents of the service report.
Table 6-18 Contents of the Service Report
Column | Data Type | Description |
---|---|---|
|
|
A sequential counter to help integrate information between related files. This value resets when the reporter restarts and is not consistent across members. However, it is helpful when trying to integrate files. |
|
|
A timestamp for each report refresh |
|
|
The service name |
|
|
The numeric member identifier |
|
|
The system time when the service information was updated from a remote member |
|
|
The number of requests since the last report refresh execution |
|
|
The number of pending requests at the time of the report |
|
|
The duration for the pending requests at the time of the report |
|
|
The number of request timeouts since the last report refresh |
|
|
The number of tasks executed since the last report refresh |
|
|
The task backlog at the time of the report |
|
|
The number of task timeouts since the last report refresh |
|
|
The number of tasks that hung since the last report refresh |
|
|
The number of threads abandoned since the last report refresh |