Some optimization configuration for TiKV

TOC.md

@@ -111,7 +111,8 @@
   + 软件调优
     + [软件版本](/tune-software-version.md) @张文博
     + 配置
-      + [TiKV 调优](/tune-tikv-performance.md) @刘玮
+      + [TiKV 线程调优](/tune-tikv-thread-performance.md) @刘玮
+      + [TiKV 内存调优](/tune-tikv-memory-performance.md) @刘玮
       + [TiFlash 调优](/tiflash/tune-tiflash-performance.md)
   + SQL 性能调优 @崔一丁
     + [SQL 性能调优概览](/sql-tuning-overview.md)

benchmark/benchmark-tidb-using-sysbench.md

@@ -87,7 +87,7 @@ sync-log = false
 capacity = "30GB"
 ```
 
-更详细的 TiKV 参数调优请参考 [TiKV 性能参数调优](/tune-tikv-performance.md)。
+更详细的 TiKV 参数调优请参考 [TiKV 内存参数性能调优](/tune-tikv-memory-performance.md)。
 
 ## 测试过程
 

benchmark/benchmark-tidb-using-tpcc.md

@@ -107,7 +107,7 @@ enabled = true
 
 ### TiKV 配置
 
-开始可以使用基本的配置，压测运行后可以通过观察 Grafana 并参考 [TiKV 调优说明](/tune-tikv-performance.md)进行调整。
+开始可以使用基本的配置，压测运行后可以通过观察 Grafana 并参考 [TiKV 线程池调优说明](/tune-tikv-thread-performance.md)进行调整。
 
 ### BenchmarkSQL 配置
 

faq/tidb-faq.md

@@ -925,7 +925,7 @@ Count 就是暴力扫表，提高并发度能显著的提升速度，修改并
 - 建议提升硬件配置，可以参考[部署建议](/hardware-and-software-requirements.md)。
 - 提升并发度，默认是 10，可以提升到 50 试试，但是一般提升在 2-4 倍之间。
 - 测试大数据量的 count。
-- 调优 TiKV 配置，可以参考[性能调优](/tune-tikv-performance.md)。
+- 调优 TiKV 配置，可以参考[线程池性能调优](/tune-tikv-thread-performance.md)与[内存性能调优](/tune-tikv-memory-performance.md)。
 
 #### 5.1.3 查看当前 DDL 的进度？
 
@@ -986,7 +986,7 @@ TiDB 中以 Region 分片来管理数据库，通常来讲，TiDB 的热点指
 
 #### 6.2.1 TiKV 性能参数调优
 
-详情参考 [TiKV 性能参数调优](/tune-tikv-performance.md)。
+详情参考[线程池性能调优](/tune-tikv-thread-performance.md) 与[内存性能调优](/tune-tikv-memory-performance.md)。
 
 ## 七、监控
 

tune-tikv-performance.md → tune-tikv-memory-performance.md

@@ -1,5 +1,5 @@
 ---
-title: TiKV 性能参数调优
+title: TiKV 内存参数性能调优
 category: reference
 aliases: ['/docs-cn/dev/reference/performance/tune-tikv/']
 ---

tune-tikv-thread-performance.md

@@ -0,0 +1,46 @@
+---
+title: TiKV 线程池性能调优
+category: reference
+aliases: ['/docs-cn/dev/reference/tikv-optimize/']
+---
+
+# TiKV 线程池性能调优
+
+本文主要介绍 TiKV 的性能调优的主要手段，以及 TiKV 内部线程池的主要用途。
+
+## 线程池介绍
+
+在 TiKV 4.0 中，线程池主要由 gRPC、Scheduler、UnifyReadPool、Raftstore、Apply、RocksDB 以及其它一些占用 CPU 不多的定时任务与检测组件组成，这里主要介绍几个占用 CPU 比较多且会对用户读写请求的性能产生影响的线程池。
+
+* gRPC 线程池处理所有网络请求，它会把不同任务类型的请求转发给不同的线程池。
+* Scheduler 线程池负责检测写事务冲突，把事务的两阶段提交、悲观锁上锁、事务回滚等请求转化为 key-value 对数组，然后交给 Raftstore 线程进行 Raft 日志复制。
+* Raftstore 线程池负责处理所有的 Raft 消息以及添加新日志的提议（Propose）、将日志写入到磁盘，当日志在多数副本中达成一致（即 Raft 论文中描述的 Commit Index）后，它就会把该日志发送给 Apply 线程。
+* Apply 线程收到从 Raftstore 线程池发来的已提交日志后将其解析为 key-value 请求，然后写入 RocksDB 并且调用回调函数通知 gRPC 线程池中的写请求完成，返回结果给客户端。
+* RocksDB 线程池是 RocksDB 进行 Compact 和 Flush 任务的线程池，关于 RocksDB 的架构与 Compact 操作请参考 [RocksDB: A Persistent Key-Value Store for Flash and RAM Storage](https://github.com/facebook/rocksdb)
+* UnifyReadPool 是 TiKV 4.0 推出的新特性，它由之前的 Coprocessor 线程池与 Storage Read Pool 合并而来，所有的读取请求包括 kv get、kv batch get、raw kv get、coprocessor 等都会在这个线程池中执行。
+
+## TiKV 的只读请求
+
+TiKV 的读取请求分为两类，一类是指定查询某一行或者某几行的简单查询，这类查询会运行在 Storage Read Pool 中；另一类是复杂的聚合计算、范围查询，这类请求会运行在 Coprocessor Read Pool 中。从 4.0 版本开始，支持两类读取请求使用同一个线程池，以减少线程数量，降低用户使用成本，默认不开启（默认点查询和 Coprocessor 请求使用不同的线程池）。用户可以通过设置配置 `readpool.storage.use-unified-pool` 为 true 来打开统一线程池。
+
+## TiKV 线程池调优
+
+* gRPC 线程池的大小默认配置（`server.grpc-concurrency`）是 4。由于 gRPC 线程池几乎不会有多少计算开销，它主要负责网络 IO、反序列化请求，因此该配置通常不需要调整，如果部署的机器 CPU 特别少（小于等于 8），可以考虑将该配置（`server.grpc-concurrency`）设置为 2，如果机器配置很高，并且 TiKV 承担了非常大量的读写请求，观察到 Grafana 上的监控 Thread CPU 的 gRPC poll CPU 的数值超过了 server.grpc-concurrency 大小的 80%，那么可以考虑适当调大 `server.grpc-concurrency` 以控制该线程池使用率在 80% 以下 （即 Grafana 上的指标低于 `80% * server.grpc-concurrency` 的值）。
+* Scheduler 线程池的大小配置 (`storage.scheduler-worker-pool-size`) 在 TiKV 检测到机器 CPU 数大于等于 16 时默认为 8，小于 16 时默认为 4。它主要用于将复杂的事务请求转化为简单的 key-value 读写。但是 **scheduler 线程池本身不进行任何写操作，**如果检测到有事务冲突，那么它会提前返回冲突结果给客户端，否则的话它会把需要写入的 key-value 合并成一条 Raft 日志交给 Raftstore 线程进行 raft 日志复制。通常来说为了避免过多的线程切换，最好确保 scheduler 线程池的利用率保持在 50%～75% 之间。（如果线程池大小为 8 的话，那么 Grafana 上的 TiKV-Details.Thread CPU.scheduler worker CPU 应当在 400%～600% 之间较为合理）
+* Raftstore 线程池是 TiKV 最为复杂的一个线程池，默认大小（`raftstore.store-pool-size`）为 2，所有的写请求都会先在 Rafttore 线程 fsync 的方式写入 RocksDB （除非手动将 `raftstore.sync-log` 设置为 false；而 `raftstore.sync-log` 设置为 false，可以提升一部分写性能，但也会增加在机器故障时数据丢失的风险）。由于存在 IO，Raftstore 线程理论上不可能达到 100% 的 CPU。为了尽可能地减少写磁盘次数，将多个写请求攒在一起写入 RocksDB，最好控制其 CPU 使用在 60% 以下。千万不要为了提升写性能盲目增大 Raftstore 线程池大小，这样可能反而会适得其反，增加了磁盘负担让性能变差。
+* UnifyReadPool 负责处理所有的读取请求。默认配置（`readpool.unified.max-thread-count`）大小为机器 CPU 数的 80%。通常建议根据业务负载特性调整其 CPU 使用率在 60%～90% 之间。
+* 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（该配置表示单次 compaction job 允许使用的子线程数量）。
+    * 如果原因是 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
+```