TCP 重传超时
Elasticsearch 集群由多个节点组成，这些节点必须保持连接，即使其中一个或多个节点关闭，或者节点之间的通信因底层基础设施的故障而中断。
TCP 通过向通信应用程序隐藏临时网络中断，在偶尔不可靠的网络上提供可靠的通信。你的操作系统会在通知发送方出现问题之前，将任何丢失的消息重传若干次。在重传发生期间，Elasticsearch 必须等待，并且只有在操作系统决定放弃之后才能做出反应。因此，用户也必须等待一系列重传完成。
大多数 Linux 发行版默认将任何丢失的数据包重传 15 次。重传以指数方式退避，因此这 15 次重传需要超过 900 秒才能完成。这意味着使用这种方法，Linux 需要很多分钟才能检测到网络分区或故障节点。Windows 默认只有 5 次重传，对应大约 13 秒的超时。
Linux 的默认值允许在可能经历很长时间丢包的网络上进行通信，但对于大多数 Elasticsearch 安装所使用的高质量网络来说，这个默认值是过度的，甚至是有害的。当集群检测到节点故障时，它会通过重新分配丢失的分片、重新路由搜索以及可能选举新的主节点来做出反应。高可用集群必须能够及时发现节点故障，这可以通过减少允许的重传次数来实现。与远程集群的连接也应比 Linux 默认值允许的速度更快地检测到故障。因此 Linux 用户应减少 TCP 重传的最大次数。
你可以通过以 root 身份运行以下命令将 TCP 重传的最大次数减少到 5。五次重传对应大约 13 秒的超时：
sysctl -w net.ipv4.tcp_retries2=5
要永久设置此值，请更新 /etc/sysctl.conf 中的 net.ipv4.tcp_retries2 设置。要在重启后验证，运行 sysctl net.ipv4.tcp_retries2。
此设置适用于所有 TCP 连接，也会影响与 Elasticsearch 集群以外系统的通信可靠性。如果你的集群通过低质量网络与外部系统通信，你可能需要为 net.ipv4.tcp_retries2 选择更高的值。因此，Elasticsearch 不会自动调整此设置。
相关配置
Elasticsearch 还实现了自己的内部健康检查，其超时时间远短于 Linux 上默认的重传超时。由于这些是应用级健康检查，其超时必须考虑到应用级的影响，例如垃圾收集停顿。你不应减少与这些应用级健康检查相关的任何超时。
你还必须确保网络基础设施不会干扰节点之间的长连接，即使这些连接看起来是空闲的。在连接达到一定期限后就将其断开的设备是 Elasticsearch 集群问题的常见来源，不得使用。