5G最大堆内存的JVM进程占满云主机8G内存该何去何从(一)

简介: 一步一步的将理论用于实战,JVM,原来如此深不见底~

背景

运维反馈,经常接到有Java进程内存占用云主机实例93%的告警,当内存持续增高,云主机会对Java进行重启,这也会影响现行业务,对实际服务有所影响。查看服务启动参数后发现最大堆内存为5G,但常常增长到7个多G,到最后出现告警及自动重启的情况,疑惑为什么之前没有类似情况暴露,回忆了下,新业务多数在此应用上开发,有进1个月的时间每天重启,导致问题来不及暴露,不禁为此展开了对该服务与JVM的研究与探讨。

排查

项目背景

项目使用openjdk8,框架为spring boot,由于该Java进程本身启动参数只设置了堆内存大小,及元空间大小,没有指定垃圾回收器也就是hotspot默认的parallel scavenge/parallel old,该GC以吞吐量优先著称,适合不需要太多交互的任务,并不适合该服务,并且gc日志的输出参数在jar 包后,被认为是spring boot项目的参数,未被认为是JVM的参数 ,因此先修复gc日志的输出,以及当oom时输出dump文件,由于直接dump进程的堆内存是对业务有影响的,而且无法自己亲自操作服务器,所以没有选择直接dump JVM的堆。

原来的启动参数如下:

java-XX:MetaspaceSize=512m-XX:MaxMetaspaceSize=512m-Xms5G-Xmx5G-Xmn2G-server-jar/home/active.jar--spring.profiles.active=prod-Xloggc:/home/logs/activegc.log-XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=5-XX:GCLogFileSize=20M-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCCause

初次修改

在垃圾收集器的选择上,我们选择一台服务器使用默认的, 一台使用cms垃圾收集器,之后基于gc日志来分析堆内存是否有问题。

#主机一使用-XX:+UseConcMarkSweepGCcms垃圾处理器java-XX:MetaspaceSize=512m-XX:MaxMetaspaceSize=512m-Xms5G-Xmx5G-Xmn2G-XX:+UseConcMarkSweepGC-Xloggc:/home/logs/activegc.log-XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=5-XX:GCLogFileSize=100M-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCCause-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/home/logs/-server-jar/home/active.jar--spring.profiles.active=prod#主机二使用默认垃圾收集器java-XX:MetaspaceSize=512m-XX:MaxMetaspaceSize=512m-Xms5G-Xmx5G-Xmn2G-Xloggc:/home/logs/activegc.log-XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=5-XX:GCLogFileSize=100M-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCCause-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/home/logs/-server-jar/home/active.jar--spring.profiles.active=prod

当默认垃圾收集器对应的Java进程触发告警时,到处gc日志,进行分析

image.png

使用cms垃圾收集器分析gc日志

image.png

以上使用的gc日志分析工具为https://gceasy.io/ 从两个日志分析来看,堆内存是比较健康的,同一时间启动以来,发现默认的垃圾收集器对内存的使用上来说是比较重的,那么我们从而得到一个简单的结论就是可以直接用cms 垃圾收集器来替换,这样可以延缓内存增速飞快导致触发告警并重启。从cms 的日志来看,老年代的内存可以少给一些,因为触发告警了需要手动重启,正好修改一下cms 垃圾收集器的java进程的内存分配,看cms进程内存的利用率并不是很高,所以替换默认垃圾收集器,使用G1看看是否更有效果。

总结

当默认的垃圾收集器触发告警时,cms 垃圾收集器内存对应的云主机内存使用率为60%,前途一片光明,战斗取得了阶段性胜利,但并不能止步,还需要进一步的研究与探索,堆内存如此健康,到底是怎么占满了8G内存的呢?

敬请期待。。。

大家加油!!!

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
相关文章
|
12月前
|
Arthas 存储 算法
深入理解JVM,包含字节码文件,内存结构,垃圾回收,类的声明周期,类加载器
JVM全称是Java Virtual Machine-Java虚拟机JVM作用:本质上是一个运行在计算机上的程序,职责是运行Java字节码文件,编译为机器码交由计算机运行类的生命周期概述:类的生命周期描述了一个类加载,使用,卸载的整个过类的生命周期阶段:类的声明周期主要分为五个阶段:加载->连接->初始化->使用->卸载,其中连接中分为三个小阶段验证->准备->解析类加载器的定义:JVM提供类加载器给Java程序去获取类和接口字节码数据类加载器的作用:类加载器接受字节码文件。
977 55
|
Arthas 监控 Java
Arthas memory(查看 JVM 内存信息)
Arthas memory(查看 JVM 内存信息)
974 6
|
消息中间件 存储 网络协议
从零开始掌握进程间通信:管道、信号、消息队列、共享内存大揭秘
本文详细介绍了进程间通信(IPC)的六种主要方式:管道、信号、消息队列、共享内存、信号量和套接字。每种方式都有其特点和适用场景,如管道适用于父子进程间的通信,消息队列能传递结构化数据,共享内存提供高速数据交换,信号量用于同步控制,套接字支持跨网络通信。通过对比和分析,帮助读者理解并选择合适的IPC机制,以提高系统性能和可靠性。
2125 14
|
缓存 Prometheus 监控
Elasticsearch集群JVM调优设置合适的堆内存大小
Elasticsearch集群JVM调优设置合适的堆内存大小
2651 1
|
存储 缓存 算法
JVM简介—1.Java内存区域
本文详细介绍了Java虚拟机运行时数据区的各个方面,包括其定义、类型(如程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区和直接内存)及其作用。文中还探讨了各版本内存区域的变化、直接内存的使用、从线程角度分析Java内存区域、堆与栈的区别、对象创建步骤、对象内存布局及访问定位,并通过实例说明了常见内存溢出问题的原因和表现形式。这些内容帮助开发者深入理解Java内存管理机制,优化应用程序性能并解决潜在的内存问题。
724 29
JVM简介—1.Java内存区域
|
缓存 监控 算法
JVM简介—2.垃圾回收器和内存分配策略
本文介绍了Java垃圾回收机制的多个方面,包括垃圾回收概述、对象存活判断、引用类型介绍、垃圾收集算法、垃圾收集器设计、具体垃圾回收器详情、Stop The World现象、内存分配与回收策略、新生代配置演示、内存泄漏和溢出问题以及JDK提供的相关工具。
JVM简介—2.垃圾回收器和内存分配策略
|
存储 算法 Java
JVM: 内存、类与垃圾
分代收集算法将内存分为新生代和老年代,分别使用不同的垃圾回收算法。新生代对象使用复制算法,老年代对象使用标记-清除或标记-整理算法。
231 6
|
存储 监控 算法
深入探索Java虚拟机(JVM)的内存管理机制
本文旨在为读者提供对Java虚拟机(JVM)内存管理机制的深入理解。通过详细解析JVM的内存结构、垃圾回收算法以及性能优化策略,本文不仅揭示了Java程序高效运行背后的原理,还为开发者提供了优化应用程序性能的实用技巧。不同于常规摘要仅概述文章大意,本文摘要将简要介绍JVM内存管理的关键点,为读者提供一个清晰的学习路线图。
|
C语言 开发者 内存技术
探索操作系统核心:从进程管理到内存分配
本文将深入探讨操作系统的两大核心功能——进程管理和内存分配。通过直观的代码示例,我们将了解如何在操作系统中实现这些基本功能,以及它们如何影响系统性能和稳定性。文章旨在为读者提供一个清晰的操作系统内部工作机制视角,同时强调理解和掌握这些概念对于任何软件开发人员的重要性。
|
运维 监控 Ubuntu
【运维】如何在Ubuntu中设置一个内存守护进程来确保内存不会溢出
通过设置内存守护进程,可以有效监控和管理系统内存使用情况,防止内存溢出带来的系统崩溃和服务中断。本文介绍了如何在Ubuntu中编写和配置内存守护脚本,并将其设置为systemd服务。通过这种方式,可以在内存使用超过设定阈值时自动采取措施,确保系统稳定运行。
645 4