图里是rocksdb CPU的监控图
有几个不理解的问题想问问
- max-background-jobs 如果CPU高只能通过max-background-jobs 加线程？
- 这个监控不管多少线程上限都是100%
我这个图里有必要加max-background-jobs线程么？
https://docs.pingcap.com/zh/tidb/stable/tune-tikv-thread-performance#线程池介绍
- RocksDB 线程池是 RocksDB 进行 Compact 和 Flush 任务的线程池，通常不需要配置。
- 如果机器 CPU 核数较少，可将
rocksdb.max-background-jobs与raftdb.max-background-jobs同时设置为 4。- 如果遇到了 Write Stall，可查看 Grafana 监控上 RocksDB-kv 中的 Write Stall Reason 有哪些指标不为 0。
- 如果是由 pending compaction bytes 相关原因引起的，可将
rocksdb.max-sub-compactions设置为 2 或者 3（该配置表示单次 compaction job 允许使用的子线程数量，TiKV 4.0 版本默认值为 3，3.0 版本默认值为 1）。- 如果原因是 memtable count 相关，建议调大所有列的
max-write-buffer-number（默认为 5）。- 如果原因是 level0 file limit 相关，建议调大如下参数为 64 或者更高：
rocksdb.defaultcf.level0-slowdown-writes-trigger
rocksdb.writecf.level0-slowdown-writes-trigger
rocksdb.lockcf.level0-slowdown-writes-trigger
rocksdb.defaultcf.level0-stop-writes-trigger
rocksdb.writecf.level0-stop-writes-trigger
rocksdb.lockcf.level0-stop-writes-trigger
cpu是几核的？
超过10核以上可能有调整max-background-jobs的意义。因为超过10核根据公式，这个值最大也就到9.小于10核，恐怕没什么调整的必要。
另外还有就是到底是否遇到了 Write Stall。这个原因会比较多。
rocksdb 线程池只做flush（把memtable持久化）和compact(压缩，可能涉及很多sst文件的调整)，隐含的意思更像是你的磁盘慢了。这个rocksdb cpu高还要关注一下磁盘的io是否够用。在考虑调整max-background-jobs参数。不然多几个线程可能作用也很有限。
CPU负载最高就是100%是吧 不会是几个线程几百？
- CPU 核数为
N时，默认值为max(2, min(N - 1, 9))这个我一直当就是9个
1 个赞
还是磁盘性能慢？ 但是看utilIO都没到100，因为用的fcsan 有网络开销所以无解？
这个n>=10的时候，就是一直是9
utilIO都没到100
感觉io还是有余力的。调大线程池可能有用。但问题是，有针对性的问题出现吗？
如果没有Write Stall，而且pending compaction bytes这个图往下掉的时间点，慢查询的监控里面也不会出现批量的insert慢查询的话，
我甚至觉得仅rocksdb cpu这个图，没有调整参数的充分理由。
因为没有针对性的问题，估计调整了以后效果也是可有可无的那种。
啥都没 就是整体速度不快 ，这个线程CPU看着一直满载 想往下降降 。那就没必要动？ 什么时候出现wirite stall在针对的调？
整体的优化，这个话题很大，我建议你看看这个视频。这个能把很多个监控串联起来，有个调优的思路和方向。
如果说你只是观察到那个满了就去调的话，我觉得意义不大。
作为一种探索或者学习向操作我是赞同的。
如果生产环境，不确定相关性，怕容易造成一些其他的麻烦。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。