近期发现很多系统在预发和线上相继出现内存占用很高的情况,但是没有内存溢出,一直到吃光内存为止,然后就开始了慢慢寻找之路 .
在此先感谢https://coldwalker.com/2018/08//troubleshooter_native_memory_increase/ 该文的大佬,提供了很多思路,路很曲折,最终是找到了原因,下面记录一下我寻找问题的过程,希望能帮助有需要的人.
从表象看
单个系统
可是jvm参数设置
加上元空间+xss等一些开销 总共也就3G不到 通过 jcmd pid VM.native_memory summary 看到大概在2.8G的样子
所以初步怀疑常驻内存是由堆外内存导致的,但是还是dump了看了一下
发现对象多的基本是string和char(其实这两个都是一样的),同时堆内存总共就172M
然后照例分析了下线程 也没发现阻塞的线程
以上分析得出:堆内内存并没有发生泄漏,很可能程序本身问题不大
然后分析堆外内存,通过BTrace来追踪下 堆外内存分配
可以参考下https://coldwalker.com/2018/03//troubleshooter_btrace01/
然后追踪了2个小时
打出了5条jboss.netty的,这个有点奇怪,公司已经升级了dubbo,dubbo2.7.3用的应该是netty4.x 而jboss.netty是3.x的情况下来的,所以怀疑会不会是jetty出来的
继续追踪,这个时候就怀疑不是程序导致的堆内和堆外的问题,这个常驻内存,是由于触发了linux某个问题导致的,然后这个时候就使用nmt来追踪下jvm在某段时间里面和内存增长.果然不出所料,堆增长大概在200M的样子,常驻内存却增长了2.5G的样子,这就说明应该是某个匿名内存块的问题.
这个时候就需要监控linux系统层面的内存分配了,使用pmap的命令来查找内存分配.
果然发现：
到这里相信网上很多教程,分析是由于glibc的效率问题,肯定是由于某处malloc申请的内存很快,free的速度跟不上,导致的,网上很多使用tcmalloc来代替的.
抱着试试看的心态去替换了(怎么替换文章一开头的大神的文章有分析),发现启动内存还是会飙升,这个时候基本处于放弃了.
死马当活马医,这个时候反正也装了谷歌的gpref，那就分析下heap
从这些个heap中分析,内存吃掉89%的,居然是有一个叫updatewindow的一个函数,好多heap文件都是这个导致的（忘记保留文件了）,这个时候好像看到了希望,然后就去找了下,发现
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8156014
当jetty的某个版本下,如果出现一些文件流的copy等的方式,可能是触发ServiceLoader的这个bug
目前公司的用是jetty9+jdk8.x 然后去搜了一些文章,发现确实有这个问题,然后看了下评论
同时jetty的作者在github上说明,问题是jdk导致的,他无法处理
所以没有换jetty版本,最终 jetty9+jdk9.x
最后用gperf监控,发现updatewindow不产生了,问题得到解决
但是最总代码中的哪里导致触发jdk8的bug,就不得而知了,可能后面还需要查下,但是公司引用开源的东西比较多,所以很难定位
