你遇到的这个问题其实在ES 2.X之后的版本里很常见——虽然旧的indices.store.throttle.max_bytes_per_sec参数被移除了，但分片恢复（副本同步的本质就是分片恢复流程）环节的默认限流刚好就是你看到的20MiB/s（对应160Mbps），这就是网络被卡主的核心原因。调index.merge.scheduler.max_thread_count没用是因为这个参数管的是分片合并的线程数，和副本同步的网络限流完全不相关。

限流的来源 #

ES在2.X之后把存储层面的全局限流拆分到了分片恢复的专属参数里，默认值刚好是20MiB/s，相关的核心参数有两个：

• indices.recovery.max_bytes_per_sec：全局控制所有分片恢复（包括副本同步）的单节点每秒传输上限，默认20mb
• indices.recovery.node_concurrent_recoveries：控制单个节点同时进行的分片恢复任务数，默认是2，这个参数会间接影响总吞吐——并发数不够的话，哪怕单任务限流调高，总速度也上不去

解除限流的方法 #

你可以通过临时动态调整（无需重启集群）或者永久配置（需要重启节点）来解决：

1. 临时动态调整（立即生效）

在Kibana Dev Tools或者用curl执行以下命令，根据你的集群网络带宽调整数值（比如如果节点间是1Gbps带宽，可以调到100mb左右，留一定余量避免网络过载）：

PUT /_cluster/settings
{
  "persistent": {
    "indices.recovery.max_bytes_per_sec": "100mb",
    "indices.recovery.node_concurrent_recoveries": "5"
  }
}

• persistent表示设置会永久保存，集群重启后依然有效；如果只是临时测试，可以换成transient，重启后失效。
• 并发恢复数建议根据数据节点数量调整，一般3-8之间比较合适，太高可能导致网络拥堵反而拖慢速度。

2. 永久配置（需重启节点）

在每个数据节点的elasticsearch.yml配置文件中添加或修改以下参数：

indices.recovery.max_bytes_per_sec: 100mb
indices.recovery.node_concurrent_recoveries: 5

修改完成后重启所有数据节点即可生效。

额外注意事项 #

• 先确认没有系统层面的限流：比如服务器是否用tc工具做了流量限制，或者云服务商的实例带宽是否被限制在160Mbps——如果是后者，需要先升级实例带宽才能突破上限。
• 调整参数时要逐步测试：可以先把限流调到50mb，观察网络使用率和集群稳定性，再逐步往上加，避免一次性拉满带宽影响其他业务。

内容的提问来源于stack exchange，提问作者Olivier D