This chapter describes predefined reports that are included with Oracle Coherence. Developers and system administrators use the reports to monitor and analyze operational statistics and troubleshoot potential problems. See Administering HTTP Session Management with Oracle Coherence*Web for reports specific to Oracle Coherence*Web.
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 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 |
|
|
|
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 storage 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 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-3 describes the contents of the flash journal report.
Table 6-3 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 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-4 describes the contents of the management report.
Table 6-4 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-5 describes the contents of the memory status report.
Table 6-5 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-6 describes the contents of the network health detail report.
Table 6-6 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-7 describes the contents of the network health report.
Table 6-7 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-8 describes the contents of the node list report.
Table 6-8 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 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-9 describes the contents of the proxy report.
Table 6-9 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-10 describes the contents of the ram journal report.
Table 6-10 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-11 describes the contents of the service report.
Table 6-11 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 |