昨天在项目测试中遇到了一个比较奇怪的问题,先说一下项目结构和环境吧
项目结构:
类型:网络监控
部署方式:web层做展现,采集层做数据采集,分析处理层做数据分析和入库,三层独立部署,运行时通过ActiveMQ来进行通信
问题描述:由于是测试阶段,数据量不太大,有20多个采集任务在运行,本机测没发现有大的问题,在服务器上跑了一夜,第二天早上发现服务器ssh登陆不上,显示连接超时。用root登陆上去,发现采集层不再采集数 据,查看日志,最早开始报异常是MQ连不上然后就是snmp也开始连上不,最后发展到内存堆溢出。
问题解决及分析步骤:
1.查看ActiveMQ日志,无任何异常,分析处理层也无异常,表明MQ并未发生故障,重启采集层后又能正常连接,再次证明MQ正常运行,MQ故障可以排除,同时分析处理层故障也可以排除
2.web层:运行在tomcat下,重启采集层后,采集层向web层通过MQ发送请求采集任务消息,能被正常处理,WEB层故障可以排除
3.问题现在定位到采集层,因此,本机启动测试,用jdk自带工具查看采集层运行情况,发现内存基本上没有多大变化,查看对象也没有占用内存多的,因此,代码逻辑错误导致内存溢出也排除,最后通过观 察一段时间的线程,发现趋势如下
每隔分钟,线程数会上升一个台阶,但我们任务调度的时候是用的quartz,里面的线程池是指定的,我们给了一个数据量级为50的线程池,通过观察发现,这50个线程是固定的,并没有增加,说明我们自己的线程池是安全的,没有发生泄漏,最终发现,随着时间不断增加,有个UDPListener线程不断在增长,但每次就长一到3个,也不太容易察觉,并且伴随UDPListener线程会有一个timer线程也是一一对应的增加,现在问题定位到了这个UDP的连接了,查看我们的采集进程 代码,用的协议各种各样的都有,最终定位到SNMP采集,虽然只写了这么几个字,但这个定位过程相当长,用了将近整个下午的时间,可能是与我经验不足有关吧,最后查看代码,发现有异常捕获,也有连接关闭,实在看不出问题到底出在哪,代码如下:
long currTime = 0;
while (!sign.isFinishedSign()) {
try {
long unit = 100;
Thread.sleep(unit);
currTime = currTime + unit;
if (currTime >= timeout) {
throw new TimeoutException(target.toString()
+ ":Donnt retrieval table data of SNMP in "
+ timeout + " millisecond.");
}
} catch (InterruptedException e) {
}
}
snmp.close();
SnmpTable t = getTable(oidEntry, ls);
t.setBorn(bornDate);
当时一看,这段代码怎么看也是正常的,后来仔细分析,发现,那个snmp.close();只要超时,就永远也运行不到,也就是说,连接永远不会关闭。当时没仔细看,以为有try catch了,异常肯定能捕获,而没注意抛出的异常和捕获的异常类型不一样,这是一点;第二点,据我同事说,这样的写法,即使后面写的是
catch (Exception e)也是捕获不到的,只能在调用这个方法的外面捕获,这个我还没有测试。最终问题解决如下
while (!sign.isFinishedSign()) {
try {
long unit = 100;
Thread.sleep(unit);
currTime = currTime + unit;
if (currTime >= timeout) {
snmp.close();//加了这个
throw new TimeoutException(target.toString()
+ ":Donnt retrieval table data of SNMP in "
+ timeout + " millisecond.");
}
} catch (InterruptedException e) {
}
}
snmp.close();
SnmpTable t = getTable(oidEntry, ls);
t.setBorn(bornDate);
到此,问题全部解决,引发采集层故障的就是这么小小的一段代码snmp.close();,唉,当时这个模块还是我们项目经理写的,技术很强的,谁也没想到会犯这种错误,处理后的运行线程监控图如下:
到此,问题是全部解决了,现在分析总结一下上面的现象,可以总结为:snmp连接没有正常关闭,导致UDP监听线程越来越多,线程不断占用socket连接,导致日志文件中记录的第一个异常发生—MQ连不上;随着时间的推移,线程越来越来,采集层对象也越来越多,最终导致内存堆溢出。至此,问题也全部分析完毕。
总结:看来我们还是不要太相信权威,呵呵 ,这算是一个典型的例子吧。再牛的人写的代码也会有bug,并且会有很低级的bug。呵呵 ,这篇文章写在这里是我自己用的备忘的,没什么技术含量,如果大家有什么好的相法和建议,可以随时和我联系,欢迎拍砖!
- 大小: 33.9 KB
- 大小: 17.1 KB
分享到:
相关推荐
软件Bug引发的十次严重后果,值得大家一看,强烈推荐。
bugfree bugfree bugfree bugfree bugfree bugfree bugfree bugfree bugfree bugfree bugfree bugfree bugfree
BugFree是一款开源的缺陷跟踪系统,专为程序代码的bug管理设计,旨在简化软件开发和测试过程中的问题追踪。在软件开发中,bug是不可避免的,BugFree提供了一个高效的平台来记录、跟踪、修复这些问题,确保项目的顺利...
BugFree 2.0 是一款专为软件测试而设计的开源Bug管理工具,它提供了高效、易用且灵活的环境来跟踪和管理软件开发过程中的缺陷。这款工具旨在帮助开发团队更好地协调工作,确保产品质量,减少错误并提高整体开发效率...
**TFS Bug 管理使用教程** 团队项目中的Bug管理是软件开发过程中的关键环节,确保产品质量和项目进度。微软的TFS(Team Foundation Server)提供了强大的Bug管理功能,与Visual Studio(VS)深度集成,同时支持Java...
QQ飞车BUG小源码
Bug 报告模板 在软件测试和质量保证过程中,_bug 报告模板是一种非常重要的文档工具。它用于记录和追踪软件中的缺陷和错误,以便在后续的开发和测试中进行修复和优化。本文将对 Bug 报告模板的主要组成部分进行详细...
而“软件测试bug统计分析图表”作为软件测试中的重要工具,扮演着至关重要的角色。本文将深入探讨这一主题,从多个角度解析其重要性、作用以及如何通过数据分析提升软件测试效率。 ### 一、软件测试与bug统计 软件...
任务管理则有助于分解大项目为小任务,分配给团队成员,提高工作效率。测试用例管理功能让测试过程规范化,确保测试覆盖率。 在使用禅道时,团队可以根据自身的工作习惯和流程定制界面和功能。禅道支持多语言,对于...
7. Reopen(再次打开的):如果经过再次测试发现 Bug(指 Bug 本身而不是包括因修复而引发的新 Bug)仍然存在的话,测试人员将 Bug 再次传递给开发组,并将 Bug 的状态设置为“Reopen”。 8. Pending Reject(拒绝...
"excel简易BUG列表管理"是一个利用Microsoft Excel构建的简单缺陷跟踪系统,适合小型团队或个人项目使用。以下是这个系统的一些核心知识点: 1. **Excel作为缺陷管理工具**: Excel是一款强大的电子表格工具,因其...
BugFree是一个开源的缺陷跟踪系统,它允许项目团队对软件开发中的错误(bug)进行记录、跟踪和管理。BugFree3.0.4是BugFree的一个版本,导出BUG的操作步骤通常涉及到以下知识点: 1. BugFree系统环境配置:BugFree...
"bug 定义和返工率计算统计方法" 本资源摘要信息主要介绍了 bug 的定义、返工率计算统计方法以及与之相关的质量提高方案。 首先,文档对 bug 的定义进行了详细的描述。bug 定义是指在软件开发过程中出现的错误或...
《Bugfree中的Bug导出与导入功能详解》 在软件开发过程中,Bug管理是一项至关重要的任务,它确保了代码质量的提升和项目进度的顺利进行。Bugfree是一款优秀的开源缺陷跟踪系统,它提供了便捷的Bug管理功能,包括Bug...
供测试使用,反馈bug模板,参考Bug解决描述Bug关闭描述(bug关闭之后由测试人员填写
原生小程序开发过程中遇到的奇怪bug以及解决方案
自己做的一个Bug统计图,大家相互参考,相互学习!
1. **复现问题**:首先,我们需要在开发环境中重现bug,这包括了理解问题现象、收集错误日志以及创建能够引发错误的最小可复现代码片段。 2. **调试工具**:Java提供了强大的调试工具JDB和IntelliJ IDEA、Eclipse等...
在软件开发过程中,BUG记录模版是至关重要的工具,它帮助团队系统地追踪、记录、汇总和分析软件中的错误或缺陷。"BUG记录模版(带汇总、统计、分析功能)"是一个专门设计用于提高缺陷管理效率的文档模版,旨在为开发...