记一次TcpListenOverflows报警解决过程

「爱情、让人受尽委屈。」 2022-01-09 23:49 1038阅读 0赞

[http://blog.csdn.net/puma\_dong/article/details/46669499][http_blog.csdn.net_puma_dong_article_details_46669499]

# 问题描述 #

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

![20150628100437310][]

此时，登陆服务器，用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发警报，于是就收到报警短信和邮件了。

这个场景下，如果我们到服务器上看看 listen情况，watch "netstat -s | grep listen"，会看到“xxx times the listen queue of a socket overflowed”，并且这个xxx在不断增加，这个xxx就是我们没有对网络请求正常处理的次数。

**参考文章：**

[关于tcp listen queue的一点事][tcp listen queue]

[如何判断是否丢掉用户请求][Link 1]

[linux里的backlog详解][linux_backlog]

[linux下socket函数之listen的参数backlog][linux_socket_listen_backlog]

[TCP SNMP counters][]

[LINUX下解决netstat查看TIME\_WAIT状态过多问题][LINUX_netstat_TIME_WAIT]

理解了以上，我们已经可以大致认为，问题的根源，就是应用处理能力不足。以下的问题分析步骤，可以继续对此进行佐证。

# 问题分析 #

## 线程栈 ##

首先看线程栈，大约12000多个线程，大量线程被TIME\_WAIT/WAIT在不同的地址，偶有多个线程被同一个地址WAIT的情况，但是都找不到这个地址运行的是什么程序，貌似这个线程栈意义不大。

关于这点，还请高手进一步帮助分析，能否可以通过这个文件直接定位问题。

## Eclipse Memory Analyzer ##

MAT分析工具，分析JVM内存dump文件，下载地址：[ http://www.eclipse.org/mat/downloads.php][http_www.eclipse.org_mat_downloads.php] 。

通过分析，我们可以看到，内存中最多的类，是socket相关的，截图如下：

![20150628101301256][]

[Shallow heap & Retained heap][Shallow heap _ Retained heap]

## Zabbix监控 ##

![20150628101430854][]

# 问题解决 #

1、申请两台新虚拟机，挂上负载。

2、Jetty调优，增大线程数，maxThreads设置为500。

3、调用外部接口Timeout时间，统一调整为3秒，3秒前端就会超时，继续让用户走别的，所以我们的后端进程继续处理已经毫无意义。

# 问题完全解决了吗？ #

找个时间，请高手帮忙分析日志，发现一个线程数太多的问题，两类线程太多（HttpClientPool、HttpMonitorCheckTimer ）；看事发时zabbix的截图，也是JVM线程很大，2万多了，并且不会减小。

![20150703151912016][]

一起定位问题，定位到一个问题，每次都会news一个HttpClientHelper，new的过程中有两件事：

1、起一个HttpMonitor线程，里面有定时任务，所以这个线程是不死的。这个线程起名了，“Executors.newScheduledThreadPool(1, new NamedThreadFactory("HttpMonitorCheckTimer"))”，所以我们看多很多叫这个名字的线程

2、起一个HttpClientPool$IdleConnectionMonitorThread线程，这个线程是定时回收池子中过期以及空闲超过一点时间的线程，这个线程没起名，所以叫Thread-XXX这样的名字

![20150703151939242][]

grep HttpClientPool 22-31.log | wc -l 11857

grep HttpMonitorCheckTimer 22-31.log | wc -l 11856

这两种线程一定是1:1的关系，都是不死的。看起来Thread-XXX的多，这是因为其他的线程，没起名字的，也是这样命名的，所以。。。所以运行Thread，还是起个名字吧。

查阅一些“PoolingHttpClientConnectionManager”线程池方式进行http调用的例子，根据HttpClientHelper的实现方式，写个PoolingHttpClientConnectionManagerDemo.java代码，运行1个小时，基本确认单例方式能正常运行；

于是修改单例方式调用HttpClientHelper，增加一点对调用次数的统计，上线。

[https://segmentfault.com/a/1190000008222890][https_segmentfault.com_a_1190000008222890]

## 三次握手 ##

![bVIFjo?w=717&h=800][bVIFjo_w_717_h_800]

## ListenOverflows ##

root@b5dbe93bcb04:/opt# netstat -s | grep listen
        22438 times the listen queue of a socket overflowed

tcp\_v4\_syn\_recv\_sock()：三路握手最后一步完成之后，Accept queue队列(完全连接队列，其大小为min(/proc/sys/net/core/somaxconn, backlog))超过上限时加１.

## ListenDrops ##

root@b5dbe93bcb04:/opt# netstat -s | grep LISTEN
        49148 SYNs to LISTEN sockets dropped

tcp\_v4\_syn\_recv\_sock()：任何原因，包括Accept queue超限，创建新连接，继承端口失败等，加１. 包含ListenOverflows的情况，也就是说当出现ListenOverflows时，它也会增加1；除此之外，当内存不够无法为新的连接分配socket相关的数据结构时，也会增加1，当然还有别的异常情况下会增加1。

## AttemptFails ##

*  tcp\_done():如果在SYN\_SENT/SYN\_RECV状态下结束一个连接，加１
 *  tcp\_check\_req():被动三路握手最后一个阶段中的输入包中如果有RST|SYN标志，加１

> 1.试图和一个不存在的套接口建立连接时，连接失败，而TcpAttemptFails同时会加1
> 
> 2.被动连接（SYN\_SEND）等待第三次握手的ack应答信号超时或者为其它的错误应答时，连接将会失败，且同时TcpAttemptFails的值将加1。

## ActiveOpens ##

客户端通过connect 发起主动打开（active open)，tcp\_connect()，发送SYN时，加１。

## PassiveOpens ##

服务器必须准备好接受外来连接。通常调用的是socket,bind和listen这三个函数来完成。我们称之为被动打开（passive open）。被动三路握手完成，加１。

## CurrEstab ##

tcp\_set\_state()，根据ESTABLISHED是新／旧状态，分别加减一。

## EstabResets ##

tcp\_set\_state()，新状态为TCP\_CLOSE，如果旧状态是ESTABLISHED／TCP\_CLOSE\_WAIT就加１。

## doc ##

*  [MIB-II TCP 组表][MIB-II TCP]
 *  [TCP netstat -az含义][TCP netstat -az]
 *  [记一次TcpListenOverflows报警解决过程][http_blog.csdn.net_puma_dong_article_details_46669499]
 *  [如何判断是否丢掉用户请求(转载)][Link 2]

*  [1月27日发布][https_segmentfault.com_a_1190000008222890]

转载于:https://blog.51cto.com/tenderrain/1975719

[http_blog.csdn.net_puma_dong_article_details_46669499]: http://blog.csdn.net/puma_dong/article/details/46669499
[20150628100437310]: /images/20220109/1f6902c299ee40fb912ecacb08b5c698.png
[tcp listen queue]: http://www.douban.com/note/178129553/
[Link 1]: http://blog.sina.com.cn/s/blog_5374d6e30101lex3.html
[linux_backlog]: http://blog.csdn.net/raintungli/article/details/37913765
[linux_socket_listen_backlog]: http://www.2cto.com/os/201207/139524.html
[TCP SNMP counters]: http://blog.chinaunix.net/uid-20695170-id-3073945.html
[LINUX_netstat_TIME_WAIT]: http://www.itokit.com/2012/0516/73950.html
[http_www.eclipse.org_mat_downloads.php]: http://www.eclipse.org/mat/downloads.php
[20150628101301256]: /images/20220109/a19e76d981a54fe49d442beb5570f367.png
[Shallow heap _ Retained heap]: http://bjyzxxds.iteye.com/blog/1532937
[20150628101430854]: /images/20220109/f283794344ad47c9be8d97386ea061c4.png
[20150703151912016]: /images/20220109/8031556817d34f37b3bc78c7650ed64b.png
[20150703151939242]: /images/20220109/3fd05dac93794293bfd68c5b707f8ccb.png
[https_segmentfault.com_a_1190000008222890]: https://segmentfault.com/a/1190000008222890
[bVIFjo_w_717_h_800]: /images/20220109/c3846b9657544210a20fe50c80cb4adb.png
[MIB-II TCP]: https://docs.oracle.com/cd/E19062-01/sun.mgmt.ctr36/819-5748/i1019580/index.html
[TCP netstat -az]: http://blog.csdn.net/scdxmoe/article/details/51822745
[Link 2]: http://carlosfu.iteye.com/blog/2253904