Database Reference
In-Depth Information
get a timeout response for executing a request made to the node. For example, a read re-
quest may get a couple of timeouts, but the user will get the data as long as there are suffi-
cient replicas that return valid responses for the request such that the consistency level of
the query is satisfied. For a write or mutate request, this means the node that has timed out
is in an inconsistent state. It will get fixed either during a read repair or an anti-entropy re-
pair operation. If you get lots of dropped messages, it may be worth investigating what is
going on in the node.
One may relate thread pools getting backed up to dropping messages in
tpstats
. There
are more tasks that can be processed by the threads within timeout limits.
compactionstats
The
compactionstats
command shows the compaction process running in the in-
stant. Compaction is a CPU- and I/O-intensive task. It may temporarily increase used disk
space. Thus, it may be a good idea to check whether any compaction is running, if there is
no obvious indication from other monitoring statistics but you suddenly see high I/O,
CPU, or space consumption. Let's take a look at the following example:
$ bin/nodetool -h 10.147.171.159 compactionstats
pending tasks: 0
Active compaction remaining time : n/a
info
The
info
command prints an overall bird's-eye view of the node's health. This command
can be used to get a quick summary of the node. Some of the labels, such as heap size and
recent cache hit rate, may give you some sense of how the node is doing. Let's take a look
at the following example:
$ bin/nodetool -h cassandra02.naishe.in info
ID : a8168502-1f0b-4537-984f-3d4e74a5ed9b
Gossip active : true
Thrift active : true
Native Transport active: true
Load : 4.85 GB
Generation No : 1417080773
Uptime (seconds) : 2490
