Database Reference
In-Depth Information
Space used (live): 29084623734
Space used (total): 29084623734
Number of Keys (estimate): 2513280
Memtable Columns Count: 345439
Memtable Data Size: 106877833
Memtable Switch Count: 1930
Read Count: 273371162
Read Latency: 5.695 ms.
Write Count: 246179400
Write Latency: 0.070 ms.
Pending Tasks: 0
Bloom Filter False Positives: 411
Bloom Filter False Ratio: 0.00000
Bloom Filter Space Used: 11691384
Compacted row minimum size: 61
Compacted row maximum size:
62479625
Compacted row mean size: 35204
The first thing you'll probably notice is that you get a total read and write count
including latencies at the keyspace level. Both of the latency values should be very
small numbers in milliseconds, typically less than 1ms. Depending on the current
state of the cluster, going up to 4ms or 5ms for read or write latency keyspace-
wide may be acceptable. Be sure to keep an eye on the number of pending tasks
listed as well. A large number here could be indicative of a larger problem such as
resource starvation or hardware issues.
On the ColumnFamily level, read and write latency should also be fairly low
values. How low the values are depends on the ColumnFamily and the use case
for that ColumnFamily. While it is definitely worth noting what the latencies are,
ultimately your query and data storage patterns will dictate what is an acceptable
range of values for those latencies.
Thread Pool Statistics
To get access to the statistics on Cassandra thread pools, you can just run node-
tool tpstats (see Listing 7.6 ). The overall goal of looking at the thread pool
statistics is to see where Cassandra is spending the majority of its time.
Search WWH ::




Custom Search