linux上TCP connection timeout的原因查找

时间:2023-12-29 11:30:26

linux上TCP connection timeout的原因查找

好久没有写文章了, 今天解决了一个网络连接超时的问题, 记录以备查看。

最近在线上nginx经常出现输出connection timeout的日志,如下格式:
2016/03/17 15:33:01 [error] 32356#0: *102974264722 no live upstreams while connecting to upstream, client: 123.151.42.*, server: localhost, request: "POST /* HTTP/1.1", upstream: "http://geo_for_gdtbid/gdtbid", host: "*.istreamsche.com"

很明显就是nginx在连接服务器时,出现了超时。一般连接超时是三次握手没有, 也就是nginx发送syn包, 服务器因为一些原因没有回复ack, 导致nginx连接超时输出日志。

server为什么没有响应ack呢, 我们知道整个链接过程不需要应用程序的参与, 应用程序只需要在连接建立后,accept请求就ok。  那么可以猜测可能是网络或系统的部分参数导致。

第一个原因,查看系统的最大打开文件数目, 此限制可能导致分配socket失败, 查看系统的允许最大文件数目, 远大于系统目前在用的socket数目。 继续网络的配置。

首先查看系统的backlog, backlog为系统的listen队列最大长度 = 接受syn队列长度 + 连接成功没有accept队列长度。

  1. cat /proc/sys/net/ipv4/tcp_max_syn_backlog

输出8192,  服务器每秒并发最大在12000左右,每个链接的生命周期平均在100ms以内, 线上不可能backlog queue不足。

继续查看: 使用命令直接查看服务器端口的队列。

  1. ss -lt

看到Send-Q在服务端口是20 ,原来在服务器端启动listen 的时候设置了20的backlog;

修改listen的参数为2048, 在次查看

  1. ss -lt

看到Send-Q在服务端口是128, 并不是2048, 其实修改为128的队列长度,此时nginx已经没有在出现connect timeout的错误。

通过详细分析查找, 发现原来内核参数也受somaxconn控制

查看

  1. cat /proc/sys/net/core/somaxconn

发现值是128, OK 原因貌似找到了,赶快修改/etc/sysctl.conf 添加:

  1. net.core.somaxconn = 8192

sysctl -f /etc/sysctl.conf 重新加载一下。

再次查看:

ss -lt

send-q 变为2048, 修改成功。