1.问题描述
产品在启动的时候会建立driver和simulator之间(driver用以驱动simulator的行为以及相互传递信息)的TCP连接用以通信,而当开始跑业务的时候应用层立即抛出“connection lost”的错误,没法再继续跑业务。该问题同样是出现在产品RHEL版本从6.7升级到7.5后出现的。
起初发现该问题所在的环境是A,driver和simulator的部署如图1所示,两者之间连接关系是N:N,可是该问题在A上只能低概率出现。后来在环境B上则可以较高概率地出现,而问题复现的条件也一直没有摸索出来。环境A和B都是RHEL7.5的系统。
图1
2.分析
我们尝试使用tshark工具抓取client端(driver)和server端(simulator)之间的数据包,也许我们可以看到他们它们怎样断开连接的,是谁先断开的等信息。以Server 1上的sim上的数据包为例,发现有多次TCP Retransmission以及Dup ACK,在开始跑业务的时候server给client端发送了RST消息,这会直接断掉连接;后来发现由于软件应用层的实现,之后driver client将会发送FIN消息给另外两个相连的simulator来断开连接,以图2中为例:
图2
我们debug调试时发现在软件启动后在这些出现问题的连接中,仅仅有driver侧提示TCP连接建立成功(即gen_tcp:connect/3返回{ok, Socket}),而simulator侧并没有这样的提示。
根据数据包中的表现找到一篇文章:TCP/IP协议中backlog参数。
我们在simulator侧的代码中的listen函数找到了backlog参数(5),而其第一个参数是socket的file description;而Linux中对此参数的系统配置值是2048,调整这里的配置是没有效果的。增大listen函数的参数后的确解决了这个问题。
所以是因为accpt queue队列长度过小,服务端没有足够的能力去监听一定规模的连接请求,导致在TCP三次握手时有一部分TCP连接没有被放入全连接队列中(客户端的ACK消息相当于没有到达服务端),那么这些连接自始至终都没有被建立好,而作为客户端,gen_tcp:connect/3的执行是无法感知这一状况的。
3.思考
- 为何升级到RHEL7.5上时出现此问题?
我们没有寻求RHEL support的帮助,但根据Paul所说,大概是RHEL7.5上监听TCP连接建立将使用更长的时间片,而如果在该时间片内出现了上述的情况,系统也无法做出什么处理,系统只会继续处理下一个时间片(包含从连接请求池中获取的下一批),而这些连接请求将会永久“搁浅”。
- 为何环境A和环境B的表现不一致?
在两个环境中复现此问题的概率有较大差别,我们想这可能是因为A有28个核心来部署driver和simulator,而B有40个,考虑到部署策略,更多的核心数意味着系统在短时间内需要处理更多的TCP连接请求,而若依然使用RHEL6.7上的参数是有可能出现问题的。
4.更进一步
其实,在应用层上也可以引入一个略有改善的方案:TCP连接请求重发。在一定时间内如果TCP连接没有一次性建立成功,可以重新发送请求,当该请求被放入新的时间片中被重新处理时,应该是可以保证其被成功处理的。
不过严格说来这会降低效率,并且不是一个万全的方法。