Database Reference
In-Depth Information
Space used (total): 379
Memtable Columns Count: 0
Memtable Data Size: 0
Memtable Switch Count: 1
Read Count: 13
Read Latency: 0.325 ms.
Write Count: 3
Write Latency: 0.133 ms.
Pending Tasks: 0
Key cache capacity: 1
Key cache size: 0
Key cache hit rate: NaN
Row cache: disabled
Compacted row minimum size: 0
Compacted row maximum size: 0
Compacted row mean size: 0
Here I have omitted lots of the output for brevity; the same statistics are generated for each
column family. We can see the latency on reads and writes, the total number of reads and writes,
the cache hit ratio, and the number of tasks that are not yet complete in the Pending Tasks count.
NOTE
Look out for a large number of pending tasks, and especially a growing number of pending tasks. This
could mean that Cassandra is running out of resources and cannot keep up. If Nodetool reveals a large
number of pending tasks, check with JMX (as shown in Chapter 9 ) or execute the tpstats command
(as we'll see next) to see what stage different tasks are in. For example, a large number of tasks in the
ROW-MUTATION-STAGE (writes) might mean that inserts, updates, or deletes are coming in faster
than Cassandra can execute them.
One thing that the statistics here show is how fast Cassandra is. Admittedly, there's very little
load on this box, but writes are executed in 1/10 of a millisecond.
Using tpstats
The tpstats tool gives us information on the thread pools that Cassandra maintains. Cassandra
is highly concurrent, and optimized for multiprocessor/multicore machines. Moreover, Cassandra
employs a Staged Event-Driven Architecture (SEDA) internally, so understanding the behavior
and health of the thread pools is important to good Cassandra maintenance.
To find statistics on the thread pools, execute Nodetool with the tpstats switch, like this:
$ bin/nodetool -host 192.168.1.5 tpstats
Search WWH ::




Custom Search