【TiDB 使用环境】生产环境
【TiDB 版本】v6.5.5
【操作系统】centos7.9
【部署方式】机器部署（什么机器配置 128c、什么硬盘 nvme 3.5T）
【集群数据量】
【集群节点数】
【问题复现路径】
【遇到的问题：问题现象及影响】
批量写入（dm同步）数据，出现server is busy，出现大量慢查询，业务侧出现大量报错，connection not avaliable
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
整体业务卡顿，qps骤降，出现了大面积慢查询，资源使用率都下来了，不知为何
meet_lock，需通过information_schema.locks查看锁持有情况，清理长事务或阻塞 SQL；connection not available大概率是连接池耗尽，可临时调大max_connections，同时优化业务侧连接复用；先查出来topsql，Kill掉，恢复正常再说其他的
问问业务方，能不能先停掉一部分
卡了1分多钟，现在是要排查原因，因为对业务造成了比较大的影响
让业务停，得需要理由，为什么会出现这种情况
批量写入是核心压力源，先通过限速避免 TiDB Server 被压垮
看一下连接数 ：TiDB_server_connections（是否接近 max_connections），并发控制：TiDB_server_concurrency_current （是否达到 tidb_server_concurrency 阈值，触发 server is busy）
弱弱的问下，现在恢复没有，问题的原因是那些，当时的处置方式是什么呢
按照业务紧急程度线停掉一部分吧
恢复了，只是卡了一瞬间，现在是排查原因
连接是20000，但是活跃会话默认只能有1000个，超过1000活跃根本连不上
如果写入过大，先停掉任务，看下是不是热点问题，批量写入的数据集中在少数 Region，导致单个 TiKV 节点负载过高
让业务停，得需要理由，为什么会出现这种情况
看我发的监控截图，资源使用率是瞬间下降了，热点问题就好说了
问题已解决，感谢社区技术支持
问题发生时触发了流控，流控后 tikv 就会拒绝一部分请求，返回 Serverisbusy 报错
流控的直接原因是 一个tikv节点 rocksdb default cf 超过了流控的阈值 20
rocksdb default cf 超阈值了， 原来是这个原因，感谢你说出来，我记下来。
