记一次生产环境的严重bug

在系统部署生产环境后, 在十天左右就会出现系统反应慢, 堆爆了,cpu占用百分百的情况。 在重启tomcat后情况就恢复了。

在经过详细的 跟踪, 线程dump, 堆dump 下来分析后, 线程没有问题,  发现有两个原因:

1: 通过memory  analyzer  分析 堆dump文件后,   有一个缓存对象无限增长,并保持活动, 导致回收不了, 堆爆掉。

2:由于后台 频繁gc, 导致系统响应慢,导致 liunx服务器的  time_wait 连接数量飙升, 参数没有设置: 将超时等待的连接用于新的连接。 导致前台请求不够。

解决方案:

1: 缓存对象 无限增长 回收不了的问题 解决方案为:  本来使用过后不用的对象应该移除的, 没有移除成功, 将此bug修复, 保持增长和移除相对稳定。

2: 超时等待的原因解决: 文章地址: https://www.aliyun.com/jiaocheng/810456.html

这个命令是查询连接数:

  netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"/t",state[key]}' 
TIME_WAIT 250263 

TIME_WAIT 250263 
CLOSE_WAIT 57 
FIN_WAIT2 3 
ESTABLISHED 2463 
SYN_RECV 8 

time_wait 数量过多:

可以修改系统的/etc/sysctl.conf配置来减少TIME_WAIT的tcp连接:
vi /etc/sysctl.conf 
net.ipv4.tcp_syncookies = 1(某些情况下该参数已启用) 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_fin_timeout = 30 

 

然后执行/sbin/sysctl -p让参数生效。再用命令查看TIME_WAIT连接数 netstat -ae | grep “TIME_WAIT” |wc -l 发现大量的TIME_WAIT 已不存在。

这个图片为:出现卡顿时的 jvisualvm 的监控, cpu使用百分比, 频繁gc, 堆使用百分百。

以下图片为 memory Analyzer 工具分析 堆dump文件的图像

以下图片为老区中 无限增长的对象的类名, 对象及大小。

猜你喜欢

转载自blog.csdn.net/tang_jian_dong/article/details/86479575