Table performance metrics
Table (formerly column family) metrics allow drilling down and locating specific areas of application workloads that are the source of performance issues. If you notice a performance trend at the OS or cluster level, viewing table metrics can provide a more granular level of detail.
Table metrics allow drilling down and locating specific areas of application workloads that are the source of performance issues. If you notice a performance trend at the OS or cluster level, viewing table metrics can provide a more granular level of detail.
The metrics for KeyCache Hits, RowCache Hits, and SSTable Size can only be viewed on a single table at a time. Otherwise, all table metrics are available for specific tables as well as for all tables on a node. In addition to monitoring read latency, write latency and load on a table, monitor the hit rates on the key and row caches for tables that rely on caching for performance. The more requests that are served from the cache, the faster the response times. Viewing SSTable Size and SSTable Count for a specific table (or counts for all tables) can help with compaction tuning.
OpsCenter has been optimized to efficiently handle thousands of tables. If a table experiences a dramatic dip in performance, check the Pending Tasks metrics for a backup in queued operations.
Table metrics are prefaced with TBL.
- TBL: Local Writes
- The write load on a table measured in requests per second. This metric includes all writes to a given table, including write requests forwarded from other nodes. This metric can be useful for tracking usage patterns of an application.
- TBL: Local Write Latency
- The response time in milliseconds for successful write requests on a table. The time period starts when nodes receive a write request, and ends when nodes respond. Optimal or acceptable levels of write latency vary widely according to your hardware, your network, and the nature of your write load. For example, the performance for a write load consisting largely of granular data at low consistency levels would be evaluated differently from a load of large strings written at high consistency levels.
- TBL: Write Latency (Stacked)
- The min, median, max, 90th, and 99th percentile of the response times to write data to a table's memtable and append to the commitlog. The elapsed time from when the replica receives the request from a coordinator and returns a response.
- TBL: Local Reads
- The read load on a table measured in requests per second. This metric includes all reads to a given table, including read requests forwarded from other nodes. This metric can be useful for tracking usage patterns of your application.
- TBL: Local Read Latency
- The response time in milliseconds for successful reads on a table. The time period starts when a node receives a read request, and ends when the node responds. Optimal or acceptable levels of read latency vary widely according to your hardware, your network, and the nature of your application read patterns. For example, the use of secondary indexes, the size of the data being requested, and the consistency level required by the client can all impact read latency. An increase in read latency can signal I/O contention. Reads can slow down when rows are fragmented across many SSTables and compaction cannot keep up with the write load.
- Read Latency (Stacked)
- The min, median, max, 90th, and 99th percentiles of a client reads. The time period starts when a node receives a client read request, and ends when the node responds back to the client. Depending on consistency level and replication factor, this may include the network latency from requesting the data’s replicas.
- TBL: Live Disk Used
- Disk space used by live SSTables. There might be obsolete SSTables not included.
- TBL: Total Disk Used
- Disk space used by a table by SSTables, including obsolete ones waiting to be garbage collected.
- TBL: SSTable Count
- The current number of SSTables for a table. When table memtables are persisted to disk as SSTables, this metric increases to the configured maximum before the compaction cycle is repeated. Using this metric together with SSTable size, you can monitor the current state of compaction for a given table. Viewing these patterns can be helpful if you are considering reconfiguring compaction settings to mitigate I/O contention.
- TBL: SSTables per Read (Stacked)
- The min, median, max, 90th, and 99th percentile of how many SSTables are accessed during a read.
- TBL: Cell Count
- The min, median, max, 90th, and 99th percentile of how many cells exist in partitions for this table.
- TBL: Partition Size
- The min, median, max, 90th, and 99th percentile of the size (in bytes) of partitions of this table.
- TBL: Pending Reads/Writes
- The number of pending reads and writes on a table. Pending operations are an indication that Cassandra is not keeping up with the workload. A value of zero indicates healthy throughput. If out-of-memory events become an issue in your Cassandra cluster, it might help to check cluster-wide pending tasks for operations that could be clogging throughput.
- TBL: Bloom Filter Space Used
- The size of the bloom filter files on disk. This grows based on the number of rows in
a table and is tunable through the per-CF attribute,
bloom_filter_fp_chance
; increasing the value of this attribute shrinks the bloom filters at the expense of a higher number of false positives. Cassandra reads the bloom filter files and stores them on the heap, so large bloom filters can be expensive in terms of memory consumption.
- TBL: Bloom Filter False Positives
- The number of false positives, which occur when the bloom filter said the row existed, but it actually did not exist in absolute numbers.
- TBL: Bloom Filter False Positive Ratio
- Percentage of bloom filter lookups that resulted in a false positive.
- TBL: Bloom Filter Off Heap
- Total off heap memory used by bloom filters from all live SSTables in a table.
- TBL: Index Summary Off Heap
- Total off heap memory used by the index summary of all live SSTables in a table.
- TBL: Compression Metadata Off Heap
- Total off heap memory used by the compression metadata of all live SSTables in a table.
- TBL: Memtable Off Heap
- Off heap memory used by a table's current memtable.
- TBL: Total Memtable Size
- An estimate of the space used in memory (including JVM overhead) for all memtables. This includes ones that are currently being flushed and related secondary indexes.
- TBL: Key Cache Requests
- The total number of read requests on the row key cache.
- TBL: Key Cache Hits
- The number of read requests that resulted in the requested row key being found in the key cache.
- TBL: Key Cache Hit Rate
- The percentage of cache requests that resulted in a cache hit that indicates the effectiveness of the key cache for a given table. The key cache is used to find the exact location of a row on disk. If a row is not in the key cache, a read operation will populate the key cache after accessing the row on disk so subsequent reads of the row can benefit. Each hit on a key cache can save one disk seek per SSTable. If the hits line tracks close to the requests line, the table is benefiting from caching. If the hits fall far below the request rate, this suggests that you could take actions to improve the performance benefit provided by the key cache, such as adjusting the number of keys cached.
- TBL: Row Cache Requests
- The total number of read requests on the row cache. This metric is only meaningful for tables with row caching configured (row caching is not enabled by default).
- TBL: Row Cache Hits
- The number of read requests that resulted in the read being satisfied from the row cache. This metric is only meaningful for tables with row caching configured (row caching is not enabled by default).
- TBL: Row Cache Hit Rate
- The percentage of cache requests that resulted in a cache hit that indicates the effectiveness of the row cache for a given table. This metric is only meaningful for tables with row caching configured (row caching is not enabled by default). The graph tracks the number of read requests in relationship to the number of row cache hits. If the hits line tracks close to the requests line, the table is benefiting from caching. If the hits fall far below the request rate, this suggests that you could take actions to improve the performance benefit provided by the row cache, such as adjusting the number of rows cached or modifying your data model to isolate high-demand rows.
- TBL: SSTable Size
- The current size of the SSTables for a table. It is expected that SSTable size will grow over time with your write load, as compaction processes continue doubling the size of SSTables. Using this metric together with SSTable count, you can monitor the current state of compaction for a given table. Viewing these patterns can be helpful if you are considering reconfiguring compaction settings to mitigate I/O contention