摘要:修改完这个,重新上线后,跑了一段时间查看情况可以看到比之前好一些了但是的次数还是比较多,照这情况下去一天的估计会有这当然是不可接受的前面说的另一个人次,飞神说如果是跑了半年的话还可以接受。
今天看JVM群里有人发了一个GC情况,让人帮忙看优化的,于是我也凑热闹发了出来想让群里的大神们指导优化一下,以下是优化过程记录.
一开始我贴了下面的两张图
jstat看GC记录
jstat -gcutil pid 1000 20
jcmd看VM参数(第一次使用这个命令)
jcmd pid VM.flags
可以看到YGC了8W多次,FGC有1100+,相比较另一个发出来求教的,我这个更糟糕,他的是运行了3天左右 FGC370次
然后飞神让我看下运行时间
ps -p pid -o etime
我的也是跑了3天左右,感觉优化空间非常的大
又让我拉了JVM配置
jinfo -flags pid(没权限,没执行成功)
ps aux | grep pid
发现我的JVM完全没做过优化,据我自己的印象,就改过PermSize,因为这个OOM过,所以调大了一点。
然后飞神给了我一份他之前用过的配置
JAVA_OPTS="-Xms2g -Xmx2g -Xmn512m -XX:MaxPermSize=256m -server -Xss256k -XX:PermSize=128M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/log/gclog/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/jvmdump/jvm.bin -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:+TieredCompilation -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:+PrintHeapAtGC
并嘱咐了一句loggc和dumpPath提前mkdir
因为已经是周五晚上了,我没有权限直接修改这个配置,所以准备下周一再配上去看效果。
万万没想到,回家路上,笨神出来说话了,要我看下存活实例
jmap -histo:live pid
由于没有开启GC日志,于是笨神让我开着jstat(飞神提到jstat -gccause pid可以跟踪gc情况),然后在另一个窗口执行jmap -histo:live
刚开始没明白,后来才知道原来这个命令可以触发Full GC
可以看到执行了Full GC以后Old区从90%降到了79%,FGC效果很差,说明活对象太多了。
回过头去看jmap实例,发现AtomicInteger这个类对象特别的多,竟然有300多万个实例,已经是top2了。
翻看代码没有发现有使用这个类的地方,初步怀疑是依赖的jar包使用的,笨神建议dump用MAT分析一下。
dump命令导出文件
jmap -dump:format=b,file=pid.dump pid
检查了一下项目代码后,发现了问题,项目代码就不贴了
项目中有一个统计API调用次数的类使用了AtomicInteger,在这个类里针对每个用户都会生成大概六七十个AtomicInteger实例,每次上报过数据之后只是简单的把值设置为0,导致负责统计的实例一直持有这些AtomicInteger,而且随着新用户的不断增加,这些实例数量还会持续增长,最终会导致内存溢出。
修改完这个BUG,重新上线后,跑了一段时间查看gc情况
可以看到比之前好一些了 但是FGC的次数还是比较多,照这情况下去一天的FGC估计会有200+,这当然是不可接受的(前面说的另一个人370次FGC,飞神说如果是跑了半年的话还可以接受)。
看了飞神推荐的阿里毕玄大师的文章为什么不建议
于是准备先不上CMS GC,就简单的把Xms,Xmn和GC日志配置了一下
-Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m -Xss256k -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/project/delivery_v9/code/logs/gc.log -XX:GCLogFileSize=50m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/project/delivery_v9/tomcat/jvmdump/jvm.dump
运行了一天左右看下对比结果
未配置
已配置
可以看到配置完以后对GC影响还是挺大的(不管是YGC还是FGC),当然这也是必然的,毕竟没有配置的机器初始内存比较小,在不断扩容的过程中会频繁的GC,而且这个时候其实没配置的那台机器内存还没有扩充到上限,在资源充足的情况下,这种动态扩容显然是完全没有必要的。
配置完的机器虽然GC时间和次数已经降了很多了,但是还是没达到期望的结果,考虑到这个程序短时间的活对象是比较多的,可以通过调整年轻代和老年代的内存占比来减少因为年轻代内存不足导致晋升到老年代的对象。
现在已经离开这个项目了,所以后面就没有再继续优化了,以后再有这方面的实践重新写文章记录。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/67552.html
摘要:相对于电子书,我更喜欢纸质版的书籍。过去的年一共阅读过本技术书,下面对这些书做一个小结。源码深度解析这本书是年购买的,年是第四次阅读。必知必会数据库的复习书籍,内容浅显易懂。 相对于电子书,我更喜欢纸质版的书籍。我喜欢在拿到新书时记录购买时间、地点、开始阅读的时间、第一次看完的时间,算是一种学习的记录。过去的2016年一共阅读过15本技术书,下面对这些书做一个小结。 《深入理解Java...
摘要:同盾技术总监张新波在第二期移动时代互联网金融的架构趋势中阐述了同盾是如何从零开始打造千万级实时风控云服务,具体介绍了同盾系统平台构建过程中主要需要解决的三大难题,以及解决这些问题的具体时实践过程。 同盾科技,是由阿里、Paypal 反欺诈专家创建的,国内第一家风险控制与反欺诈云服务提供商,其涉及领域包括电商、B2B、互联网金融、游戏等。同盾技术总监张新波在 UPYUN Open ...
摘要:的字节码解释器和编译器使用写屏障维护卡表。解释器每次执行更新引用的字节码时,都会执行一段写屏障,编译器在生成更新引用的代码后,也会生成一段写屏障。 4. JVM 4.1 GC 1. 垃圾收集 基础 : 可达性分析算法 GC ROOTS 复制算法 标记清除 标记整理 分代收集 -- 1. 新生代 ; 2.3 老年代注: Oop Map -- 安全点 -- 安全区 以下部分内容 来自 ...
摘要:而热部署技术能够帮助开发人员减少重新部署的等待时间。本文的目的为调研热部署的技术现状及其对开发效率的帮助,并简单梳理其技术实现的难点。热部署技术总结热部署目前有多种技术实现官方开源商业。 开发、自测、联调期间代码可能会被频繁地修改,通常即使只增加了一行代码,都需要重启容器以检查执行效果。而热部署技术能够帮助开发人员减少重新部署的等待时间。本文的目的为调研热部署的技术现状及其对开发效率的...
面试官:今天要不来聊聊JVM调优相关的吧?面试官:你曾经在生产环境下有过调优JVM的经历吗?候选者:没有面试官:...候选者:嗯...是这样的,我们一般优化系统的思路是这样的候选者:1. 一般来说关系型数据库是先到瓶颈,首先排查是否为数据库的问题候选者:(这个过程中就需要评估自己建的索引是否合理、是否需要引入分布式缓存、是否需要分库分表等等)候选者:2. 然后,我们会考虑是否需要扩容(横向和纵向都...
阅读 1370·2021-11-22 09:34
阅读 2580·2021-11-12 10:36
阅读 1111·2021-11-11 16:55
阅读 2324·2020-06-22 14:43
阅读 1456·2019-08-30 15:55
阅读 1974·2019-08-30 15:53
阅读 1763·2019-08-30 10:50
阅读 1216·2019-08-29 12:15