tikv是否存在流量控制参数，防止过载导致集群业务严重超时

🪐 TiDB 技术问题
1

【 TiDB 使用环境】测试
【 TiDB 版本】v7.6.0
【复现路径】持续打流，加大并发，scan流量过大时，tikv时延剧增
【遇到的问题：问题现象及影响】流量较大时，tikv时延剧增
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

2

TiKV 组件对写入有流控 https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#storageflow-control
你这种异常的 SQL，建议使用资源管控功能去控制，保证正常业务 SQL 稳定，参考 https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control-ru-groups
如果你这不是异常 SQL，那就需要考虑集群资源是否合理，业务设计是否合理啦，规划好测试好满足业务要求再上线

3 个赞
3

资源管控用的就是流控的经典算法——令牌桶算法。

4

tikv时延剧增，看看是哪些操作增加的延迟，优化操作是比较可行的方法

5
  1. 请求队列深度控制
    通过scheduler-concurrency参数（默认值 2048）限制事务调度器的最大并发处理能力，当写入请求堆积超过队列阈值时，TiKV 会自动触发流控拒绝新请求。同时配合scheduler-pending-write-threshold（默认 100MB）控制内存中的待处理数据量，防止内存溢出导致的性能雪崩。
  2. 读写工作线程池隔离
    采用 Unified Read Pool 技术，通过readpool.unified.max-thread-count参数动态分配读请求的处理线程数，实现读操作与写操作的资源隔离。当检测到线程池排队延迟超过readpool.unified.max-tasks-per-worker阈值时，自动触发限流降级。
  3. Raft 处理流控机制
    在 RaftStore 层通过raftstore.store-pool-size控制日志持久化线程数，配合raftstore.apply-pool-size参数限制状态机应用线程数。当单个 Region 的 Proposal 数量超过raftstore.inspect-interval周期内的处理能力时，会触发流控拒绝新提案。
  4. 网络带宽配额管理
    基于 gRPC 流量拦截器实现网络层 QoS 控制，通过server.grpc-concurrency限制每个 TiKV 实例的最大并发连接数，同时使用server.grpc-memory-pool-quota参数控制网络缓存池的内存分配，避免网络缓冲区膨胀导致 OOM。
  5. 动态优先级降级策略
    针对 OLAP 大查询场景，通过quota.foreground-cpu-time和quota.foreground-write-bandwidth参数为高优先级请求保留基础资源配额。当系统检测到cpu-usage或disk-iops超过阈值时，自动将批量导入等后台任务的资源配额进行动态压缩。
6

可以看看是不是有热点。