[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version]
[Reproduction Path] What operations were performed when the issue occurred
[Encountered Issue: Problem Phenomenon and Impact] How to query the number of application threads in RocksDB
[Resource Configuration] Go to TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
[Attachment: Screenshot/Logs/Monitoring]
For configuration, use SHOW config WHERE NAME LIKE ‘%apply-pool-size%’
Check this, the default is 2. Generally, if the usage rate above reaches 200%, you can consider scaling up.
The RocksDB thread pool is used for Compact and Flush tasks in RocksDB and usually does not need to be configured.
If the machine has a small number of CPU cores, you can set rocksdb.max-background-jobs and raftdb.max-background-jobs to 4.
If you encounter a Write Stall, you can check the Write Stall Reason in RocksDB-kv on Grafana monitoring to see which indicators are not zero.
If it is caused by pending compaction bytes, you can set rocksdb.max-sub-compactions to 2 or 3 (this configuration indicates the number of sub-threads allowed for a single compaction job, the default value is 3 in TiKV 4.0 and 1 in version 3.0).
If the reason is related to memtable count, it is recommended to increase the max-write-buffer-number for all columns (default is 5).
If the reason is related to level0 file limit, it is recommended to increase the following parameters to 64 or higher:
The Apply thread pool is responsible for persisting data to disk. This configuration item specifies the number of threads in the Apply thread pool, i.e., the size of the Apply thread pool. When adjusting the size of the Apply thread pool, please refer to TiKV Thread Pool Tuning.
Default value: 2
Adjustable range: [1, CPU * 10]
Apply refers to converting the content of raftlog to Kv and then writing it to rocksdb.