JVM调优 一次平凡却有点累的经历

299 阅读2分钟

简要说一下原因的话就是 公司要求布一个微众银行开源的DSS,说白话就是一个大数据可视化的SQL开发平台,前端做的比较好想做一下竞品分析,但是他们官方的沙箱环境又老是维护,给了一台机器让先试试

由于dss是一个基于Spring Cloud的分布式微服务框架 而且做了权限控制的操作,我必须要把主服务器启动才能访问前端界面,挨个排查进程 看了下dss-framework-project-server这个微服务没起来 准备手动重启

结果一上来 进程直接死了 连OOM都没有,连忙排查内存,CPU。然后发现 133.jpeg

传说中的 CPU 200% 终于还是让我遇上了

排查出来的原因是在oung gc引起的cpu 100%
但是日志最后是现实在young gc remark之后输出gc cleanup 进入stop the world

原因: 重标记的时候 由于大对象过多, young gc太长了, 造成长时间GC停顿

解决方法: 感觉排查方向有三个

  • 大对象的大小没有设置好 需要重新设置(G1HeapRegionSize)

  • 开启指针压缩 , 尽量避免因为字节对齐造成大对象过大

  • 关闭jvm分层编译 默认的Server Compile 全局分析,所以启动速度会变慢

  • 设置并行的GC线程数 ParallelGCThreads和ConcGCThreads 本机已经起了18个进程 启动的时候写gc log的线程,抢不到cpu时间片 造成进程挂掉 所以ParallelGCThreads从16 -> 4 调整 目标是想要降低gc线程的切换成本

参考G1的调优参数 在8core 16G的机器上调整内存后 打印的参数如下:

Java HotSpot(TM) 64-Bit Server VM (25.181-b13) for linux-amd64 JRE (1.8.0_181-b13), built on Jul  7 2018 00:56:38 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)
Memory: 4k page, physical 65808308k(5236388k free), swap 8257532k(8143868k free)
CommandLine flags: -XX:CompressedClassSpaceSize=260046848 -XX:ConcGCThreads=16 -XX:G1HeapRegionSize=33554432 -XX:InitialHeapSize=524288000 -XX:InitiatingHeapOccupancyPercent=45 -XX:MaxGCPauseMillis=200 -XX:MaxHeapSize=524288000 -XX:MaxMetaspaceSize=268435456 -XX:MetaspaceSize=268435456 -XX:ParallelGCThreads=16 -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:ReservedCodeCacheSize=268435456 -XX:-TieredCompilation -XX:+UseCodeCacheFlushing -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC

cpu的利用率从 200% -> 175% 但是 还是挂掉了

于是咨询一下perfma的dalao 建议机器规格扩大, 问题持续的时间久一点,顺着这个往回查

4581660380465_.pic.jpg

4591660380466_.pic.jpg

4601660380467_.pic.jpg

4611660380467_.pic.jpg

最后dss-framework-project-server 单独布一台机器上 可以是可以了 但是感觉逃避了问题本质 哎