Tomcat7.0.26的连接数控制bug的问题排查

标签: JAVA Web bug tcp tomcat | 发表时间:2014-04-26 08:00 | 作者:sunqi
出处:http://ifeve.com

感谢同事[ 空蒙]的投稿。

首先感谢@烈元一起排查此问题。今天发现线上一台机器,监控一直在告警,一看是健康检查不通过,就上去查看了下,首先自己curl了下应用的url,果然是超时没有响应,那就开始按顺序排查了:

1、 load非常低,2、gc也正常,3、线程上也没死锁,4、日志一切正常。那是什么情况呢,不能忘记网络啊。果然,netstat命令一把,结果如下:

TIME_WAIT 68
CLOSE_WAIT 194
ESTABLISHED 3941
SYN_RECV 100

问题出来了,SYN_RECV竟然达到100个,正常情况下,半连接的请求应该是很小的。而且我们机器是内部的,不是lvs,不太会有半连接攻击,怎么可能达到这么大呢?

再grep SYN_RECV的连接,看到全部都是nginx在连接这台mtop机器,那接下来就dump tcp包看看了

image001
一看一堆堆的wjas向mtop发起SYN连接请求,可是mtop机器是绝大部分没回应,只有极少的mtop机器syn+ack包。
注:wjas一天向mtop发起了近20亿的健康检查请求,够多的,所以没有外部流量时,还是有一大堆的http请求到应用上。

看系统信息,内核是2.6.32-220.23.2.ali1113.el5.x86_64的,半连接队列的长度是128不同的内核,半连接队列长度算法稍有不同,可以参考文章: linux诡异的半连接(SYN_RECV)队列长度

可见是mtop半连接队列满了,不再接受新的tcp连接,导致请求没有响应了,但应用其实很空闲。

问题表现很清楚了,接下来就是各种怀疑了,因为这机器为解决之前tcnative的crash bug,刚切换成了nio模式、又昨天我手贱,在上面搞过btrace,aliperf。自己也成嫌疑,但这是半连接队列满,要么受到半连接攻击(排除,内网不太可能有半连接攻击),要么是Accept线程没有及时处理,应用没有接收连接的请求,导致三次握手后的队列连接满再引起半连接队列满了。(总结起来好像很有逻辑,排查的时候没那么明确的,还在想各种可能)

我们知道,tomcat有一个Acceptor线程,监听在端口上,在收到连接请求后,会立刻把请求交个后面线程池处理,bio是直接拿线程等待数据,nio与apr会在poller线程上注册监听,也就是select模式,底层再基于epoll事件触发(和nginx的处理模式有点区别)。那就是这个Acceptor线程难道停止了。

查看堆栈信息,果然

image002当前的这个acceptor已经被禁用了,需要唤醒,多次dump线程,发现此线程一直是这个状态,这就解释了为什么了。

马上查看tomcat源码,发现此代码是在tomcat的连接数(nio)达到1w的时候,会park当前线程,再请求处理后,会再唤醒,继续接受新的连接,Btrace了一把,果然这个连接数值是1w,但什么情况下,会导致这个值那么大,一直把线程暂停呢?按说如果要达到这么大的连接,我们的T4机器早就鸡飞狗跳了。

Google一把,原来是 tomcat7.0.27之前的bug,我们使用的刚好是7.0.26.中枪了,不管是nio,bio,apr,都存在这个问题。Tomcat的代码如下:

image003-3当接受连接,出现异常时候,旧版本没有把这个数组减少,这时候就拼人品了,如果异常的请求累积,达到连接的最大值,就发生机器很闲,但tcp的连接队列与半连接队列满的情况了

tomcat在7.0.28修复了此问题,参见 Tomcat 7 Changelog 。

1、如有遇到此类似情况,可看看是否这原因。
2、当最新版的jar或者容器稳定后,早点升级吧,特别是bug修复。
3、提供一次问题排查的参考。

(全文完)如果您喜欢此文请点赞,分享,评论。





您可能感兴趣的文章

相关 [tomcat7 控制 bug] 推荐:

tomcat7之websocket

- - ITeye博客
从tomcat7.0.26之后开始支持websocket,建议大家使用tomcat7.0.30,期间版本的接口有一些改动. chrome默认支持websocket. 其他浏览器可能由于安全原因,默认是关闭的. // 与7.0.27不同的,Tomcat改变了createWebSocketInbound方法的定义,增加了一个HttpServletRequest参数.

Tomcat7.0.26的连接数控制bug的问题排查

- - 并发编程网 - ifeve.com
首先感谢@烈元一起排查此问题. 今天发现线上一台机器,监控一直在告警,一看是健康检查不通过,就上去查看了下,首先自己curl了下应用的url,果然是超时没有响应,那就开始按顺序排查了:. 1、 load非常低,2、gc也正常,3、线程上也没死锁,4、日志一切正常. 那是什么情况呢,不能忘记网络啊. 果然,netstat命令一把,结果如下:.

Tomcat7配置双向SSL

- - CSDN博客推荐文章
//ca-cert.pem即为CA根证书,可将其下发到客户端,导入作为根证书.  如果按请求生成CA证书,由证书申请者生成请求文件certreq.txt. CA端执行签名,生成证书文件1.cer. 4.将证书导出成浏览器支持的.p12格式,密码changeit. 4.将证书导出成浏览器支持的.p12格式 :.

tomcat7特性 serlvet async特性

- - 编程语言 - ITeye博客
每个请求来到Web容器,Web容器会为其分配一个线程来专门负责该请求,直到完成处理前,该执行线程都不会被释放回容器. 执行线程会耗用系统资源,若有些请求需要长时间处理(例如长时间运算、等待某个资源),就会长时间占用执行线程. 若这类的请求很多,许多执行线程都被长时间占用,而在web容器内,可以使用的线程都是有限的,这对于系统就会是个负担,甚至造成应用程式的性能瓶颈.

找bug记(1)

- BTK 4eVeR - BlogJava-庄周梦蝶
    转载请注明出处 http://www.blogjava.net/killme2008/archive/2011/07/10/354062.html.     上周在线上系统发现了两个bug,值得记录下查找的过程和原因. 以后如果还有查找bug比较有价值的经历,我也会继续分享.     第一个bug的起始,是在线上日志发现一个频繁打印的异常——java.lang.ArrayIndexOutOfBoundsException.

找bug记(2)

- gengmao - BlogJava-庄周梦蝶
    这篇blog迟到了很久,本来是想写另一个跟网络相关bug的查找过程,偷偷懒,写下最近印象比较深刻的bug. 这个bug是我的同事水寒最终定位到的.     前几个月同事报告称有一个线上MQ集群会同一时间抛出ArrayIndexOutOfBoundsException这个异常,也就是数组越界.

(原)CentOS_linux5.5、JDK1.6、tomcat7、nginx、mysql5.1、mongodb安…

- - Linux - 操作系统 - ITeye博客
转: http://blog.sina.com.cn/s/blog_438308750100xsb5.html. # 关闭不需要的服务按上面的安装关闭 ip6tables、jexec、kudzu、lvm2-monitor、mcstrans、netfs、rawdevices、restorecond. 2.禁止Ctrl+Alt+Delete重新启动机器命令.

Scrum中管理bug

- - CSDN博客研发管理推荐文章
如果bug来自于正在开发的sprint. 会在task阶段就被QA/Scrum Master/Product Owner标记为有bug,并且Story不能被置为done状态,这个很容易解决. 如果bug来自于已经结束的sprint,那么怎么办呢. 理想状态下是将bug放到backlogs中,然后由product owner调整其优先级,并决定放在后面的哪一个sprint中修复.