在我们的设置中,我们一直收到“对等连接重置” mongo错误。 设置说明:
我们收到这些错误。我们观察到,如果存在一系列调用,例如500个调用以执行基于键的选择,则没有问题。 然后我们暂停5分钟,然后重复测试,这是我们第一次收到“对等方重置连接”的信息。稍后,测试将继续。 每次暂停后都会发生这种情况。
这种情况会随着真实用户的行为而重复发生,可能会突然出现活动,然后停顿下来。结果,我们在业务工作流的关键部分不断获得“对等连接重置”。在客户端,解决方案是执行防御性编码并重复呼叫,但这在许多地方都是一个变化。
尝试其他组合:
但是行为没有改变。
在我们看来,虽然在服务器端关闭了TCP连接,但是客户端仍然认为这是有效连接,并尝试使用它,从而导致此错误。
还有其他人遇到过这种情况吗?任何建议将不胜感激,如有需要,我们乐意提供更多信息。
答案 0 :(得分:1)
在AKS上运行的集群有一个非常相似的问题。我设法将其追溯到conntrack看到(或认为正在看到)tcp重传。这是一个示例,其中客户端pod为10.3.0.8,服务器pod为10.3.0.113,查看运行mongo的节点上的conntrack条目:
conntrack -L|grep "10\.3\.0\.113"|grep "10\.3\.0\.88"
conntrack v1.4.3 (conntrack-tools): 1091 flow entries have been shown.
tcp 6 86398 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=34919 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=34919 [ASSURED] mark=0 use=1
tcp 6 86398 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=33389 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=33389 [ASSURED] mark=0 use=1
tcp 6 86390 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=39917 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=39917 [ASSURED] mark=0 use=1
tcp 6 51 TIME_WAIT src=10.3.0.88 dst=10.3.0.113 sport=36649 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=36649 [ASSURED] mark=0 use=1
tcp 6 298 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=35033 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=35033 [ASSURED] mark=0 use=1
tcp 6 299 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=44131 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=44131 [ASSURED] mark=0 use=1
您可以看到有些条目的超时时间很短(298/299秒)-它们以86400秒(/ proc / sys / net / netfilter / nf_conntrack_tcp_timeout_建立)开始,但已移至300秒(nf_conntrack_tcp_timeout_max_retrans) 。我可以肯定地是这种情况,因为更改nf_conntrack_tcp_timeout_max_retrans会更改上面的超时值。
我目前不知道为什么会发生重传,但是知道您的问题是否相同很有趣。
对于我来说,可以通过将nf_conntrack_tcp_timeout_max_retrans增加到> 10分钟,或将mongo空闲连接超时减少到<5分钟来解决。