为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】4.0.8
【问题描述】集群大量小包传输，导致软中断很高，系统吞吐量上不去
通过 iptraf-ng 抓取tipd server网络信息， 几秒时间 数据包 就达到100万，但是网络流量却很少。
首先说明下您提的问题，并不是一个通俗问题。
在您这个问题背后我只能大胆的猜测下
PD节点 作为 TIDB 集群的 原信息存储和 TSO 发放的核心节点，网络通信频繁是比较正常的
-
在数据写入时候 2PC 的 2 次 TSO 获取， 都需要在 PD Leader 节点获取。
-
tikv 上的数据存储 每一组 Region Group （默认 3 副本）都需要定期向 PD 同步心跳
-
每个存储节点也需要定期向 PD 同步 心跳
综上
如果 集群相关 region 较多 ，且存储有大量冷数据或半冷数据 建议开启 tikv 上 hibernate region 功能 ，减少 region 心跳，并同时调整 region down peer 的 同步时间从 5m 到 10m。
如果 从 TiDB 的监控面板 查看 PD TSO duration 延迟较高。需要排查是 pd leader 网络问题还是 PD 的资源配置不足
如果 PD leader 能满足 8C 2.2GMHZ 16G MEM 的需求 TSO 发放的效能在 百万量级
如果以上都没有回答您的问题请先按照如下 文档自行排查下。明确下是服务器硬件资源问题还是文档中的其他问题
TiDB 读性能慢
TiDB 写性能慢
3节点(PD+TIDB ) 3KV节点 都是32c 128G 内存， 目前2T左右的数据，大概有12万的region, 算多吗？ 能开启region 合并吗？
刚才确认了一下 raftstore.hibernate-regions: true 这个配置已经打开了！！
集群挂了一个 tiflash 节点 ，如果tiflash 有瓶颈 影响tidb的写入吗？
tiflash 不影响写入
三个问题一块回复哈
问题 1
3节点(PD+TIDB ) 3KV节点 都是32c 128G 内存， 目前2T左右的数据，大概有12万的region, 算多吗？ 能开启region 合并吗？
答复： 机器配置还是可以的 。tidb+PD 的混部基本满足需求
需要注意的是 这个配置可能是云主机。磁盘带宽和 IOPS 可能不能达到理想配置
建议 IO 测试成绩
4K IO 随机读 顺序写 IOPS 达到 10000 以上
256K IO 顺序写 带宽达到 1GB 带宽
这样在写性能和 TIKV 上的 region 调度和 compaction 时候 IO 资源才能不成为瓶颈
一般一个 KV 实例管理 3~5w region 数量是合理的，但数据量 2T。可能存在空的 region 建议开启 region 合并。
问题 2
raftstore.hibernate-regions: true 已经顶开了
建议配合再调整下 max-peer-down-duration 从 5m 调整到 10 min
这是因为 hibernate-regions 的检测时长是 5m，有可能和 down-peer 检测时长冲突。调整 down-peer 检测时长可以避免这一问题
问题 3
集群挂了一个 tiflash 节点 ，如果tiflash 有瓶颈 影响tidb的写入吗
tiflash 挂掉不会影响 tidb 的写入 。这主要归功于 tiflash 的region 副本数据是以 leaner 角色存在的，并不参与 raft 选举。
但tiflash的可用性会影响 数据的读取，造成读操作失败
在新的版本中会加入 tiflash 的可用性调度的功能。如果 tiflash 节点不可用，会退化到使用 tikv 节点进行数据查询
1 个赞