TCP 重传超时
编辑TCP 重传超时
编辑每对 Elasticsearch 节点通过多个 TCP 连接进行通信，这些连接保持打开，直到其中一个节点关闭或节点之间的通信因底层基础设施故障而中断。
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 集群的常见问题来源，必须避免使用。