linux tcp connection timeout,linux上TCP connection timeout的原因查找

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队列长度。

cat /proc/sys/net/ipv4/tcp_max_syn_backlog

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

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

ss -lt

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

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

ss -lt

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

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

查看

cat /proc/sys/net/core/somaxconn

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

net.core.somaxconn = 8192

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

再次查看：

ss -lt

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