记一次TcpListenOverflows报警解决过程

 

问题描述

 

2015-06-25，晚上21:33收到报警，截图如下：

此时，登陆服务器，用curl检查，发现服务报500错误，不能正常提供服务。

 

问题处理

 

tail各种日志，jstat看GC，不能很快定位问题，于是dump内存和线程stack后重启应用。

jps -v，找出Process ID

jstack -l PID > 22-31.log

jmap -dump:format=b,file=22-29.bin PID

 

TcpListenOverflows

 

应用处理网络请求的能力，由两个因素决定：

1、应用的OPS容量（本例中是 就是我们的jetty应用：controller和thrift的处理能力）

2、Socket等待队列的长度（这个是os级别的，cat  /proc/sys/net/core/somaxconn 可以查看，默认是128，可以调优成了4192，有的公司会搞成32768）

当这两个容量都满了的时候，应用就不能正常提供服务了，TcpListenOverflows就开始计数，zabbix监控设定了>5发警报，于是就收到报警短信和邮件了。

这个场景下，如