TiDB压测过程中tps一会儿高一会儿低

[Hacker_hnSEntrA]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
【概述】压测TiDB,tps有时候高，有时候低，大概是1小时左右的周期
【背景】
【现象】性能一会儿高一会儿低
【业务影响】
【TiDB 版本】5.1.0
【附件】
监控.rar (6.3 MB)

• 相关日志 和 监控

1. TiUP Cluster Display 信息

2. TiUP Cluster Edit Config 信息

3. TiDB- Overview 监控

• 对应模块日志（包含问题前后1小时日志）

[leeray (Lileiaab)]

麻烦把监控数据截图看看，目前给的信息太少，没办法判断具体原因呢。

一会高一会低是不是某台主机有消耗大量资源的定时任务在跑，从而周期性影响集群性能。

[苏州刘三枪]

tikv的机器配置发一下，qps和cpu的曲线很像，可能是CPU跑满了导致的。

[Hacker_hnSEntrA]

tikv的机器是56c的，112G

[苏州刘三枪]

看一下这2个指标的配置是多少，有可能是这里的CPU使用满了。
gRPC.grpc-concurrency
readpool.unified.max-thread-count

[Hacker_hnSEntrA]

grpc-concurrency = 24
max-thread-count=20

[苏州刘三枪]

尝试调大这2个参数跑一下试试，其他的监控指标看起来没啥异常。

[Hacker_hnSEntrA]

这两个参数已经很大了啊。

[yilong (yi888long)]

1. 请问 raftstore.store-pool-size 和 raftstore.apply-pool-size 的参数值配置的是多少？
2. 网卡是千兆还是万兆网卡？
3. 您压测的方法大概是什么？
4. 目前看可能 qps 和 coprocessor cache 关系比较大。由于select 占了大多数，所以select的影响较大。业务是否会有很多相同的查询？或者说模拟的数据，大部分都查了同一个或者几个值？
   
   
   
   
   
   
   
   

[Hacker_hnSEntrA]

这个coprocessor cache hit的图是我自己搞出来的，是个次数，不是比例。所以当qps低的时候，cache数目低也是正常。
store-pool-size和apply-pool-size是6。
通过压测真实业务的一个api测试。
网卡是万兆卡
我自己看监控，可能是和部分tikv有关。

[Lucien]

【概述】压测TiDB,tps有时候高，有时候低，大概是1小时左右的周期
【背景】
【现象】性能一会儿高一会儿低

能否提供一下压测的模型和配置 ？

[yilong (yi888long)]

业务压测模型呢？确认下这个，多谢。

[Hacker_hnSEntrA]

监控过期了，找不到当时的监控信息了， 结帖了，等再遇到再说吧。感谢各位。