【 TiDB 使用环境】生产环境
【 TiDB 版本】6.5.8
【遇到的问题：问题现象及影响】使用spark任务进行数据读取性能验证，前面5min左右，pd的cpu使用率很高，被打满，后面慢慢降下来并趋于稳定，导致qps也是相应从比较低到较高并趋于稳定。有什么优化的方法，或者有哪些集群的参数调整，可以降低pd开始的cpu使用，不被打满，使得qps一开始便比较高，提升总体的读取性能
【附件：截图/日志/监控】
https://docs.pingcap.com/zh/tidb/stable/grafana-pd-dashboard#pd-重要监控指标详解
pd监控面板上和这个cpu同步升高的指标有哪些？
首先还是要看看这个时候pd到底在忙什么。pd的功能总的来说就是tso，调度，心跳这几件事。和读取相关的大概率还是tso相关的指标。查查看是否有同步升高的。
也可以看 balance, split 等 panel 看看是否有 region 相关问题。
绑定 numa
PD 有几个参数可以调整，优化其性能：
- max-grpc-send-msg-size 和 max-grpc-recv-msg-size：增大这两个参数可以允许 PD 处理更大的消息，从而减少交互次数。适当调整这些参数可以降低 PD 的 CPU 使用率。
- leader-schedule-interval：增大此参数的值可以减少 PD 在选举和调度中的频繁操作。
- replication.max-replicas：根据集群的负载情况调整副本数。副本过多会增加 PD 的负担。
balance-leader和transfer-leader初期都高
1 个赞
pd绑numa会好一些
1、看看CPU都均衡不；
2、禁用numa，避免跨核。
这像是有读取热点，才会疯狂balance。
https://docs.pingcap.com/zh/tidb/stable/dashboard-key-visualizer#tidb-dashboard-流量可视化页面
同时期的流量可视化页面是什么样的？
有哪些参数可以帮助调优下
- 你发的截图是调度时间长，这个可能是 tikv 压力当时大导致的。你可以看下 Operator create 相关 OPS 高不高，这是任务数。而且调度一般吃不了这么高的 cpu
- 你截图 1 cpu usage 是服务器 cpu 使用率。还是 pd 进程的 cpu 使用率
- 如果是 pd 进程 cpu 高，你业务模型什么样的？前五分钟是不是不一样。不通负载不带表申请 tso 一样，可能导致压力不一样。
参数调整可以考虑楼上有说的 max-grpc-send-msg-size 那些参数。就是攒批处理 tso。降低 cpu 不过会提高一定的 duration。
tikv与tidb的cpu都没有被打满，没到瓶颈，只有pd的cpu很高，被打满。 tso和balance-leader、transfer-leader都高。spark任务进行读数据的压测，前5分钟和后面是一致的。
max-grpc-send-msg-size 和 max-grpc-recv-msg-size都没有找到，只有tikv的参数 max-grpc-send-msg-len
leader-schedule-interval这个参数也没有找到