博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
linux上TCP connection timeout的原因查找
阅读量:7209 次
发布时间:2019-06-29

本文共 1196 字,大约阅读时间需要 3 分钟。

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, 修改成功。

转载地址:http://xrrum.baihongyu.com/

你可能感兴趣的文章
易买网总结
查看>>
C#导入Excel报错问题。
查看>>
网站前端性能优化
查看>>
课后作业
查看>>
C#反射学习
查看>>
实验二 直线DDA生成算法的GDI实现
查看>>
发现博客园的网站结构真不错啊
查看>>
团队作业七
查看>>
迭代器与泛型for
查看>>
在idea中用tomcat远程部署调试
查看>>
HGE引擎改进
查看>>
存储过程执行失败与sql668n
查看>>
Android面试题3之描写叙述下Android的系统架构
查看>>
2014-7-20 谁还认得这几本书?
查看>>
基于django搭建网站
查看>>
c++ 循环程序的作业,2017年10月10日作业题。
查看>>
从C语言结构对齐重谈变量存放地址与内存分配
查看>>
NSTimer_Block封装定时器的target-action成Block回调
查看>>
FileInfo类和DirectoryInfo类
查看>>
B. Obtaining the String(模拟)
查看>>