tidb参数调优，服务器资源充足情况下哪些参数可以调大

🪐 TiDB 技术问题
1

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】生产环境 /测试环境
【TiDB 版本】
【部署方式】云上部署（什么云）/机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU 256核 内存 1T nvme磁盘3.5T*3
【集群数据量】
【集群节点数】6
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】在服务器资源充足的情况下，哪些数据库参数可以调大

2

机器配置很豪华，256核1T内存，可以重点调这几个：

TiKV 侧：

  • raftstore.store-pool-size 调到 8-12
  • raftstore.apply-pool-size 调到 8-12
  • storage.block-cache.capacity 建议给到内存的 45% 左右，比如 400G
  • readpool.unified.max-thread-count 设为 CPU 的 60-80%，约 160
  • rocksdb.max-background-jobs 调到 16-32

TiDB 侧：

  • tidb_distsql_scan_concurrency 默认 15，可调到 30-50
  • tidb_index_lookup_concurrency、tidb_index_serial_scan_concurrency 适当调大
  • tidb_executor_concurrency 默认 5，可调到 10-15

注意： 别一次全调，改完观察监控再继续，尤其 block-cache 太大会挤占系统内存导致 OOM。建议先在测试环境验证。

1 个赞
3

好的我们调整试试

4

线程池参数跳过挺多的，但实际表现并没有多少提升 :clown_face:

5

主要还是看看有没瓶颈吧。 要是现有资源都很充足，调大也是用不上的吧。
就像4车道的高速，平时就只是占俩车道，扩成八车道也没用啊。

6

如果是信创服务器，操作系统也可以调优一下试试

8

抽空我们也优化下，看看调优后有没有性能变化

9

资源充足的前提下，TiKV 优先调大 rocksdb block_cache，收益最高；TiDB 可以调大查询内存配额、临时存储限额；PD 的并发调度参数只在扩容迁移时临时放大。切记分批调参，观察监控，不要一次性全部开大。

10

调TIKV BLOCK CACAHE

11

先别堆线程池，看 Performance Overview 里 scheduler worker cpu 和 async request 等待，确认瓶颈在不在 raftstore。gRPC 并发默认才 4，256 核能上 8~16，比 store-pool-size 管用。

12

block-cache给内存45%，readpool按核数配

13

如果不是混合部署，调整参数作用都一般般

14

资源充足的情况下，收益最大的还是 TiKV 的 storage.block-cache.capacity，默认是系统内存的 45%，混部的话要手动压一下。然后是 TiKV 的 grpc-concurrency 和 readpool 按核数配，别一次开太大。TiDB 侧就是调查询内存配额和临时存储限额，tidb_mem_quota_query 和 tidb_server_memory_limit 这两个。PD 的并发调度参数只在扩容、迁移的时候临时放大，平时不用动。

说句实话，不是混部单实例的话调参收益都比较有限，先把慢 SQL 和热点解决掉比调参有效得多。调的时候记得分批调、看监控~

15

这些机器配置太给力了，实际数据量大吗？数据量不大的话感觉所有热点数据都可以存到block-cache里面了

16

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。