tidb节点网络负载高

TiDBer_BHNvzjBT · 2026 年8 月 4 日 01:34

【 TiDB 使用环境】生产环境
【 TiDB 版本】7.1.5
【复现路径】正常部署完成后运行
【遇到的问题：】3节点kv异常，网络层传输异常
【资源配置】3节点服务器都是16核64GB
资源图ip错了，可以不用管，实际ip为172.30.249.93,92,87

【集群数据量】约 800GB
【附件：截图/日志/监控】

节点1网络

节点2网络

节点3网络
节点一的发送网络流量大致等于节点2和节点3的接收流量
业务服务使用量不大，入口流量很小。通过iotop和nethogs查看基本都是tikv端口数据发送和接收。查看tikv日志如下日志居多

不知道是啥原因导致的， region-schedule-limit 设置的128 leader-schedule-limit 设置的4 hot-region-schedule-limit 设置的2，实在不明白啥原因了，希望广大网友给分析下看看

TiDBer_bawpguhQ · 2026 年8 月 4 日 01:40

TiKV 网络负载高先对照 Dashboard：Hot Region、Store 流量、gRPC 重试/耗时，以及是否有大表扫描/备份/Region 调度打满网卡。常见是热点 Region 或副本迁移过猛。处理：定位热点表键、打散写入；临时降 PD 调度速度；确认交换机/网卡是否打满或丢包。3 节点网络异常时优先查节点间连通与 MTU。

克里克里克 · 2026 年8 月 4 日 01:59

先看看是不是region频繁调度，leader是不是频繁迁移

独善其身 · 2026 年8 月 4 日 02:11

Region Leader 高度集中在 TiKV 节点 1（最高概率）

原理

TiDB Raft 协议：每个 Region 只有 1 个 Leader，所有 Raft 日志（写入、快照）由 Leader 推送给另外两个 Follower 副本。场景：绝大多数 Region Leader 落在节点 93。

节点 1：向外发送 Raft Log → 网卡出口打高
节点 2、3：接收复制日志 → 入流量上涨完美匹配你的监控特征：节点 1 发送流量≈节点 2+3 接收总和

为什么 Leader 不均衡？

PD 默认均衡策略优先均衡 Region 数量，不强制均衡 Leader；
集群初始化、数据导入后，Leader 天然聚集；
leader-schedule-limit=4 设置过小！

leader 调度限速只有 4，PD 迁移 Leader 速度极慢，无法自动打散 Leader。

Loving · 2026 年8 月 4 日 10:14

一个tidb,一个tikv，混合部署的情况下很难判断出是谁影响了谁，我们之前也是类似的问题，拆开后就清楚多了。

kang · 2026 年8 月 5 日 00:33

看你的描述，节点1发送流量≈节点2+3接收，典型的单点数据分发模式。结合日志居多的情况，大概率是Raft日志复制或调度搬迁在跑。

建议按顺序排查：

先看PD调度监控，确认是否有大量leader/region迁移。你region-schedule-limit=128太高了，生产建议降到8-16，不然容易引发网络风暴。
检查TiKV详情-Thread CPU，看raftstore和apply线程是否打满，如果打满说明是日志复制瓶颈。

Lucien-卢西恩 · 2026 年8 月 7 日 02:32

重点区分三种情况：

store 中 93 节点的 leader_count 明显更高，同时 hot write 也集中在该节点：更像写热点或 Leader 分布问题。
operator show region 有大量任务，Grafana 同期存在 Snapshot 流量：更像 Region 搬迁产生的网络流量。
Leader/Region 数量基本均衡且没有调度任务：需要结合端口、TiDB/TiKV 混合部署情况及业务 SQL 流量继续定位。

建议再补充：

store、operator show、hot write 的输出。
三台服务器的完整组件部署关系。
TiKV 日志中重复出现的 20–30 行原始文本，不要只发截图。
TiKV-Details 中 Raft message、Snapshot、gRPC 和磁盘写入的同期曲线。

在确认原因前不建议直接降低或提高调度参数。官方也说明，除非明确理解影响，否则不推荐自行修改 region-schedule-limit。PD Control 使用说明

当前证据只能说明存在明显的 TiKV 内部网络流量，还不足以判定为网络故障或产品缺陷。