| Heap max |
The maximum amount of shared memory allocated to the JVM heap for Cassandra
processes. |
| Heap used |
The amount of shared memory in use by the JVM heap for Cassandra
processes. |
| JVM CMS collection count |
The number of concurrent mark-sweep (CMS) garbage collections performed by the
JVM per second. |
| JVM ParNew collection count |
The number of parallel new-generation garbage collections performed by the JVM
per second. |
| JVM CMS collection time |
The time spent collecting CMS garbage in milliseconds per second
(ms/sec). |
| JVM ParNew collection time |
The time spent performing ParNew garbage collections in ms/sec. |
| Data size |
The size of column family data (in gigabytes) that has been loaded/inserted
into Cassandra, including any storage overhead and system metadata. |
| Compactions pending |
The number of compaction operations that are queued and waiting for system
resources in order to run. The optimal number of pending compactions is 0 (or at
most a very small number). A value greater than 0 indicates that read operations are
in I/O contention with compaction operations, which usually manifests itself as
declining read performance. |
| Total bytes compacted |
The number of sstable data compacted in bytes per second. |
| Total compactions |
The number of compactions (minor or major) performed per second. |
| Flush sorter tasks pending |
The flush sorter process performs the first step in the overall process of
flushing memtables to disk as SSTables. The optimal number of pending flushes is 0
(or at most a very small number). |
| Flushes pending |
The flush process flushes memtables to disk as SSTables. This metric shows the
number of memtables queued for the flush process. The optimal number of pending
flushes is 0 (or at most a very small number). |
| Gossip tasks pending |
Cassandra uses a protocol called gossip to discover location and state
information about the other nodes participating in a Cassandra cluster. In
Cassandra, the gossip process runs once per second on each node and exchanges state
messages with up to three other nodes in the cluster. Gossip tasks pending shows the
number of gossip messages and acknowledgments queued and waiting to be sent or
received. The optimal number of pending gossip tasks is 0 (or at most a very small
number). |
| Hinted handoff pending |
While a node is offline, other nodes in the cluster will save hints about rows
that were updated during the time the node was unavailable. When a node comes back
online, its corresponding replicas will begin streaming the missed writes to the
node to catch it up. The hinted handoff pending metric tracks the number of hints
that are queued and waiting to be delivered once a failed node is back online again.
High numbers of pending hints are commonly seen when a node is brought back online
after some down time. Viewing this metric can help you determine when the recovering
node has been made consistent again. |
| Internal response pending |
The number of pending tasks from various internal tasks such as nodes joining
and leaving the cluster. |
| Manual repair tasks pending |
The number of operations still to be completed when you run anti-entropy repair
on a node. It will only show values greater than 0 when a repair is in progress. It
is not unusual to see a large number of pending tasks when a repair is running, but
you should see the number of tasks progressively decreasing. |
| Memtable postflushers pending |
The memtable post flush process performs the final step in the overall process
of flushing memtables to disk as SSTables. The optimal number of pending flushes is
0 (or at most a very small number). |
| Migrations pending |
The number of pending tasks from system methods that have modified the schema.
Schema updates have to be propagated to all nodes, so pending tasks for this metric
can manifest in schema disagreement errors. |
| Miscellaneous tasks pending |
The number of pending tasks from other miscellaneous operations that are not
ran frequently. |
| Read requests pending |
The number of read requests that have arrived into the cluster but are waiting
to be handled. During low or moderate read load, you should see 0 pending read
operations (or at most a very low number). |
| Read repair tasks pending |
The number of read repair operations that are queued and waiting for system
resources in order to run. The optimal number of pending read repairs is 0 (or at
most a very small number). A value greater than 0 indicates that read repair
operations are in I/O contention with other operations. |
| Replicate on write tasks pending |
When an insert or update to a row is written, the affected row is replicated to
all other nodes that manage a replica for that row. This is called the
ReplicateOnWriteStage. This metric tracks the pending tasks related to this stage of
the write process. During low or moderate write load, you should see 0 pending
replicate on write tasks (or at most a very low number). |
| Request response pending |
Streaming of data between nodes happens during operations such as bootstrap and
decommission when one node sends large numbers of rows to another node. The metric
tracks the progress of the streamed rows from the receiving node. |
| Streams pending |
Streaming of data between nodes happens during operations such as bootstrap and
decommission when one node sends large numbers of rows to another node. The metric
tracks the progress of the streamed rows from the sending node. |
| Write requests pending |
The number of write requests that have arrived into the cluster but are waiting
to be handled. During low or moderate write load, you should see 0 pending write
operations (or at most a very low number). |
