博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
一个Tomcat配置参数引发的血案
阅读量:4605 次
发布时间:2019-06-09

本文共 2060 字,大约阅读时间需要 6 分钟。

转载:https://mp.weixin.qq.com/s/3IuTcDCTB3yIovp6o_vuKA

一、现象

有用户反馈访问PC首页偶尔会出现白页情况,也偶尔会收到听云的报警短信

 

二、监控(听云和JVMVISUAL)

刚开始去听云监控看到偶尔有几分钟报500,然后就又好了,而且没有详细的堆栈信息,但是日志显示调用的接口有熔断发生,所以初步怀疑是熔断造成,因为刚开始设置的熔断是600MS,后来调整到2s、10s,但是依然无效,依然有500的出现。换思维,通过jvisualvm进行监控,分别从cpu、内存、类、线程几个方面进行分析。经过一段时间观察得到如下结论:

1.cpu没有太大波动,看起来垃圾回收还比较合理,图形如下:

2.堆(存放类的实例、数组)看起来比较正常,也能正常回收; 非堆:(8以下,存放方法区[又叫永久区,存放类的类型信息、常量池、域信息、方法信息,大部分来源于class文件]、JVM内部处理或优化所需内存等其他meta-data);metaspace又叫元空间, 属于非堆区(java8以上,替换了之前的永久区[方法区]),图形出现了异常,呈现阶段性上升。

                                                        异常

                                                             异常

3.加载的类(共享和独有类???),发现类似异常,随时间会有阶段性增长

                                               异常

4.线程,呈现阶段性波动,说明当时是有异常的

 

                                          

三、深入分析

整体的现象如上图所示,

1、首先排除线程是否存在死锁导致内存溢出。

可以借助Jconsole来查看线程是否存在死锁,或是通过jstack里查找LOCKED

通过检查以上不存在线程死锁,可以排除这种情况。

2、接着查看当时的访问量曲线,基本平稳,没有太大的流量波动(可以从听云吞吐率图形来看

3.查看内存占用最大的线程及内存增量大的线程,以及程序的问题

 

从图中可以看出ContainerBackgroundProccessor线程无论是从总量还是增量都是占用最高的,我们先看了我们代码中是否有内存泄漏情况,从下图可以看到程序内并没有占用很高的情况,说明程序代码并未出现内存泄漏,关键在ContainerBackgroundProccessor线程问题

 

于是百度,也未查到相关资料,但从名字看起来像是tomcat 容器类,于是从听云监控查找出问题的日期,发现从8月26号之后出现的,在看jeckins构建记录,在25号并未提交新功能,只是做了tomcat升级,于是对照未升级的tomcat运行状况,发现只有更新后的tomcat会出ContainerBackgroundProccessor线程一直占用较高的情况,而且所有升级的项目都有这个问题,但是由于其他项目都采用了4g内存所以不明显,但WEB又被改成2g内存了,于是猜想是由于tomcat升级后引起了内存溢出。

 

于是开始对比8.0.33和8.5.15.0两个版本的区别

将web项目的tomcat回退到8.0.33,经过几天的观察,运行稳定,没有出现类似问题,而且那个线程内存和cpu占用也极低,接近0。

为了稳定考虑,最终决定将所有项目先回退tomcat,但为什么新版本会出现这样的问题?于是猜想要么升级后的tomcat本身有问题,要么是配置文件,要么是JVM参数问题。如果是tomcat版本bug的话,网上肯定会有人提,本着对tomcat信任的原则,先排除另外两个。

首先,运维对JVM参数进行了调优,经过测试后再次重现,于是排除了JVM参数问题;
接着换思路,如果是配置文件的话,都有哪些不一样?于是开始对比tomcat下的几个文件context.xml和server.xml,发现了在server.xml中的  
reloadable这个参数是不一样的,于是查了下该参数:reloadable:如果这个属性设为true,  Tomcat服务器在运行状态下会监视在WEB-INF/classes和Web-INF/lib目录CLASS文件的改运.如果监视到有class文件被更新,服务器自动重新加载Web应用。虽然看起来很智能,但是一旦设置成true,ContainerBackgroundProccessor线程就会占用很高内存,将近98%,从而导致内存溢出,服务不正常等问题,理论上生产环境禁止设置成false。于是把测试环境的这个参数改了下,之前那个ContainerBackgroundProccessor线程所占内存和cpu立即降到几乎为0,回到正常。

 

四、结论

升级tomcat后,但tocmat配置并未按原先的配置,之前的reloadable=false设置成了reloadable=true导致了内存溢出。所以我们在生产环境对tomcat或配置的修改一定要慎重,大到容器,小到一个参数都有可能引发血案。另外就是我们要学会通过JConsole和JvmVisual来进行有效监控,便于定位和分析问题。

转载于:https://www.cnblogs.com/ceshi2016/p/8463099.html

你可能感兴趣的文章
除了 iOS 和 Android,世界第三大移动系统是什么?
查看>>
35.7. FAQ
查看>>
深搜算法实例:老鼠走迷宫(一)
查看>>
VMWare网络设置的3中方式(转)
查看>>
支付这条线上 谁在赚钱谁在哭?
查看>>
机器学习之朴素贝叶斯分类
查看>>
亚信安全参加第六届全国等保技术大会 态势感知助力“等保2.0”落地
查看>>
【设计模式系列】--抽象工厂
查看>>
JqueryValidate 动态添加验证
查看>>
双活数据中心的架构
查看>>
大数据公司Palantir融得7亿美元 曾追踪拉登
查看>>
先行者长虹佳华超融合市场沙龙在京举行
查看>>
建立备份策略的重要性
查看>>
小白用户如何轻松上云 -我的轻量应用服务器探索记
查看>>
BCG与阿里研究院等联合揭秘中国互联网经济:成功的关键是什么?
查看>>
发力IoT领域 Marvell注重生态系统发展
查看>>
数据中心网络布线工程必备七大件
查看>>
20个问题揭穿冒牌数据科学家
查看>>
你应该知道的 RPC 原理
查看>>
Ubuntu安装词典
查看>>