本文记录了一次由于TcpListenOverflows报警导致的服务故障处理过程。通过对线程栈、内存分析和Zabbix监控的数据，确定了问题根源是应用处理能力不足。解决方案包括增加服务器、调整Jetty配置和优化外部接口超时时间。尽管问题得到缓解，但后续日志分析发现线程过多问题，特别是HttpClientPool和HttpMonitorCheckTimer线程，最终通过改用PoolingHttpClientConnectionManager并采用单例模式优化了HTTP调用。
问题描述
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发警报，于是就收到报警短信和邮件了。
这个场景下，如
最低0.47元/天 解锁文章
扫一扫
1488
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
