`
dary_zhou
  • 浏览: 39271 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论

解决EOS因为程序引起系统宕机或者运行缓慢的快速定位方法

    博客分类:
  • EOS
JVM 
阅读更多

应用中查询结果非常大时,会占用比较多的内存,造成系统内存不足,引起OOM错误或者系统运行缓慢,重新启动应用后系统恢复正常。当碰到这种问题时, 很难有一个比较有效的办法来找到问题代码。系统在大多数据的时候是正常运行,只是某一种数据条件满足的情况下造成,可能是操作者从地址栏中直接修改一些参数时才发生。

   对于这一类问题,可以通过如下几步可以快速的定位到问题代码。

a)       下载引起系统出问题前后两个小时内的的useraccessmonitor.log.

b)      通过EOS性能分析工具,找出内存突变的时间段,也就内存突然被大量占用。

c)       在性能分析日志文件中

                       i.  内存突然增加:
内存突然增加表示程序执行过程中突然占用了大量内存。在JVM使用的内存列中可以看到。

                     ii.  查找空闲内存突然增加前一两分钟内的请求所有请求。一般会有很多请求是相同的,去掉相同的请求,可以缩小范围,加快定位速度。 

找到可疑的PR,然后用UE打开Useraccessmonitor.log.查找请求ID

  可以看到本次请求执行的全过程,如果未执行完成的BIZ,找到未执行完的BIZ,当中和肯定有数据库查询,找到可能在某种情况下没有条件时占用大量内存的代码。

日志文件中,@@B 表示开始,@@E 表示结束。

用户ID如果为NULL,这个请求就是BIZ,有用户ID的则是PR.

每一个BIZ的执行完成后,都会成对出现开始和结束标志。从最外层BIZ开始,可以找到整个BIZ的执行过程,并对可能产生大数据量的查询条件进行归避。

EOSLOG查找相同的请求ID,综合分析,可以更快找到问题代码。

EOS5.3中可以通过工具直接分析出未结束的BIZ,这样就可以更快找到问题所在。

总之:在分析这一类问题时关键是要找到未执行完成的BIZ。在系统未消占用大量内在之前,BIZ都会执行完成,只有不能正常执行完成那才是问题的关键。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics