Project: YugabyteDB (App Definition and Development / Database)
File: cache-storage.md

title: Cache and storage subsystem metrics headerTitle: Cache and storage subsystems linkTitle: Cache and storage metrics headcontent: Monitor RocksDB storage subsystem metrics description: Learn about YugabyteDB's cache and storage subsystem metrics, and how to select and use the metrics. menu: v2.18: identifier: cache-storage parent: metrics-overview weight: 120 type: docs uses a modified version of RocksDB (an LSM-based key-value store that consists of multiple logical levels, and data in each level are sorted by key) as the storage layer. This storage layer performs `seek`, `next`, and `prev` operations. The following table describes key throughput and latency metrics for the storage (RocksDB) layer. | Metric | Unit | Type | Description | | : | : | : | :- | | `rocksdbnumberdb_next` | keys | counter | Whenever a tuple is read/updated from the database, a request is made to RocksDB key. Each database operation makes multiple requests to RocksDB. The number of NEXT operations performed to look up a key by RocksDB when a tuple is read/updated by the database. | | `rocksdbnumberdb_prev` | keys | counter | The number of PREV operations performed to look up a key by RocksDB when a tuple is read/updated from the database. | | `rocksdbnumberdb_seek` | keys | counter | The number of SEEK operations performed to look up a key by the RocksDB when a tuple is read/updated from the database.| | `rocksdbdbwrite_micros` | microseconds | counter | The time spent by RocksDB in microseconds to write data.| | `rocksdbdbget_micros` | microseconds | counter | The time spent by RocksDB in microseconds to retrieve data matching a value. | | `rocksdbdbseek_micros` | microseconds | counter | The time spent by RocksDB in microseconds to retrieve data in a range query. | These metrics can be aggregated across the entire cluster using appropriate aggregations. When the data requested from YSQL layer is sitting in an SST File, it will be cached in RocksDb Block Cache. This is the fundamental cache that sits in RocksDB instead of the YSQL layer. A block requires multiple touches before it is added to the multi-touch (hot) portion of the cache. The following table describes key cache metrics for the storage (RocksDB) layer. | Metric | Unit | Type | Description | | :-- | : | : | :- | | `rocksdbblockcache_hit` | blocks | counter | The total number of block cache hits (cache index + cache filter + cache data). | | `rocksdbblockcache_miss` | blocks | counter | The total number of block cache misses (cache index + cache filter + cache data). | | `blockcachesingletouchusage` | blocks | counter | Blocks of data cached and read once by the YSQL layer are classified in single touch portion of the cache.The size (in bytes) of the cache usage by blocks having a single touch. | | `blockcachemultitouchusage` | blocks | counter | Blocks of data cached and read more than once by the YSQL layer are classified in the multi-touch portion of the cache. The size (in bytes) of the cache usage by blocks having multiple touches. | These metrics can be aggregated across the entire cluster using appropriate aggregations. Bloom filters are hash tables used to determine if a given SSTable has the data for a query looking for a particular value. | Metric | Unit | Type | Description | | : | : | : | :- | | `rocksdbbloomfilter_checked` | blocks | counter | The number of times the bloom filter has been

| | `rocksdbbloomfilter_useful` | blocks | counter | The number of times the bloom filter has avoided file reads (avoiding IOPS). | These metrics can be aggregated across the entire cluster using appropriate aggregations. RocksDB LSM-trees buffer incoming data in a memory buffer that, when full, is sorted, and flushed to disk in the form of a sorted run. When a sorted run is flushed to disk, it may be iteratively merged with existing runs of the same size. Overall, as a result of such iterative merges, the sorted runs on disk (also called Sorted-String Table or SST files) form a collection of levels of exponentially increasing size with potentially overlapping key ranges across the levels. | Metric | Unit | Type | Description | | : | : | : | :- | | `rocksdbcurrentversionsstfiles_size` | bytes | counter | The aggregate size of all SST files. | | `rocksdbcurrentversionnumsst_files` | files | counter | The number of SST files. | These metrics can be aggregated across the entire cluster using appropriate aggregations. To make reads more performant over time, RocksDB periodically reduces the number of logical levels by running compaction (sorted-merge) on the SST files in the background, where part or multiple logical levels are merged into one. In other words, RocksDB uses compactions to balance write, space, and read amplifications. A description of key metrics in this category is listed in the following table: | Metric | Unit | Type | Description | | : | : | : | :- | | `rocksdbcompactread_bytes` | bytes | counter | Number of bytes being read to do compaction. | | `rocksdbcompactwrite_bytes` | bytes | counter | Number of bytes being written to do compaction. | | `rocksdbcompactiontimes_micros` | microseconds | counter | Time for the compaction process to complete. | | `rocksdbnumfilesin_singlecompaction` | files | counter | Number of files in any single compaction. | Memtable is the first level of data storage where data is stored when you start inserting. It provides statistics about reading documents, which are essentially columns in the table. If a memtable is full, the existing memtable is made immutable and stored on disk as an SST file. Memtable has statistics about reading documents, which essentially are columns in the table. | Metric | Unit | Type | Description | | : | : | : | :- | | `rocksdbmemtablecompaction_micros` | microseconds | counter | Total time to compact a set of SST files. | | `rocksdbmemtablehit` | keys | counter | Number of memtable hits. | | `rocksdbmemtablemiss` | keys | counter | Number of memtable misses. | These metrics are available per tablet and can be aggregated across the entire cluster using appropriate aggregations. The Write Ahead Log (or WAL) is used to write and persist updates to disk on each tablet. The following table describes metrics for observing the performance of the WAL component. | Metric | Unit | Type | Description | | : | : | : | :- | | `logsynclatency` | microseconds | counter | Time spent to flush (fsync) the WAL entries to disk. | | `logappendlatency` | microseconds | counter | Time spent on appending a batch of values to the WAL. | | `loggroupcommit_latency` | microseconds | counter | Time spent on committing an entire group. | | `logbyteslogged`| bytes | counter | Number of bytes written to the WAL after the tablet starts. | | `logreaderbytes_read` | bytes | counter | Number of bytes read from WAL after the tablet start. | These metrics are available per tablet and can be