草庐IT

“堆内存持续占用高 且 ygc回收效果不佳” 排查处理实践

京东云开发者 2023-03-28 原文
作者：京东零售　王江波

说明：部分素材来源于网络，数据分析全为真实数据。

一、 问题背景

自建的两套工具，运行一段时间后均出现 内存占用高触发报警，频繁young gc且效果不佳。曾经尝试多次解决，因各种原因耽搁，最近下定决心处理此问题。

二、 问题描述

Q：堆内存1018M，使用达到950M左右触发一次young gc，ygc之后内存占用630M，未发生full gc



三、 容器配置

已处理关键信息

•主机名 xxx

•实例ID xxx

•ip

•操作系统名称Linux

•操作系统体系结构amd64

•CPU个数2

•JRE版本1.8.0_191

•JVM启动时间2023-02-18 17:14:10.873

•启动路径/export/App

•Full GCPS MarkSweep

•Young GCPS Scavenge

•进程ID115135

•物理内存大小251.4GB(269888389120Byte)

•交换区大小0.0GB(0Byte)

•虚拟内存大小12.5GB(13368197120Byte)

•应用路径/export/App/lib/tp-center-web.jar!/BOOT-INF/lib/

•JVM启动参数-javaagent:/export/xxx/lib/pfinder-profiler-agent-1.0.8-20210322032622-6f12bda2.jar -Ddeploy.app.name=xxx -Ddeploy.app.id=xxx -Ddeploy.instance.id=0 -Ddeploy.instance.name=server1 -DJDOS_DATACENTER=HT -Dloader.path=./conf -Dspring.profiles.active=pre -Xms1024m -Xmx1024m -Xmn384m -XX:MetaspaceSize=64m -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=2 -XX:CICompilerCount=2 -XX:MaxDirectMemorySize=128m -Duser.timezone=Asia/Shanghai -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=xxx -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=xxx

四、 问题分析

1、 young gc的时机？
R：ygc在新生代的eden区满了之后就会触发，采用复制算法回收新生代的垃圾。

2、 为何young gc后堆内存使用率仍然很高？
R：新生代过小，大对象直接进入老年代，编码时要尽量减少大对象的使用。

3、 full gc 的时机？
R：HotSpot VM里，除了CMS之外，其它能收集老年代的GC都会同时收集整个GC堆，包括新生代

1） 发生fgc之前进行检查，如果 老年代可用的连续内存空间 < 新生代历次ygc后升入老年代的对象总和的平均大小，此时先触发old gc，然后执行ygc

2） 执行ygc之后有一批对象需要放入老年代，此时老年代没有足够空间存放对象，必须触发一次ogc

3） 老年代内存使用率超过阈值，也要触发ogc

4） 元空间不足时也会触发一次

4、 什么原因导致内存占用高？
R：heap dump分析、gc日志

五、 回收器

•吞吐量优先（Parallel Scavenge）：新生代收集器，侧重于吞吐量（吞吐量=运行用户代码时间/(运行用户代码时间+运行垃圾收集时间)）的控制。

•Serial Old：Serial Old是Serial收集器的老年代版本， 它同样是一个单线程收集器， 使用标记-整理算法：由于老年代 Serial Old 收集器在服务端应用性能上的“拖累”, 使用Parallel Scavenge 收集器也未必能在整体上获得吞吐量最大化的效果。由于单线程的老年代收集中无法充分利用服务器多处理器的并行处理能力, 在老年代内存空间很大而且硬件规格比较高级的运行环境中, 这种组合的总吞吐量甚至不一定比ParNew加CMS的组合来得优秀。

•Parallel Old ：是 Parallel Scavenge 收集器的老年代版本, 支持多线程并发收集, 基于标记-整理算法实现. 这个收集器是直到 JDK 6 时才开始提供的, 在此之前, 新生代的 Parallel Scavenge收集器一直处于相当尴尬的状态, 原因是如果新生代选择了 Parallel Scavenge 收集器, 老年代除了 Serial Old(PS MarkSweep)收集器以外别无选择

UseParallelGC: JDK9 之前虚拟机运行在 Server 模式下的默认值, 使用 ParallelScavenge + Serial Old(PS MarkSweep)的收集器组合进行内存回收。

UseParallelOldGC: 打开此开关后, 使用 Parallel Scavenge + Parallel Old 的收集器组合进行内存回收。

•ParNew收集器与Parallel收集器类似：此收集器是许多运行在Server模式下的虚拟机的首选，除了Serial收集器外，只有它能与CMS收集器配合工作

•并发标记清除（CMS）回收器：是一种以获取最短回收停顿时间为目标的回收器，该回收器是基于“标记-清除”算法实现的。注重回收时产生的停顿时间，是停顿时间最短的收集器。非常适合注重用户体验的应用上，是Hotspot虚拟机第一款真正意义上的并发收集器，第一次实现了让垃圾收集线程与用户线程几乎同时运行

六、 优化策略

1、 加gc日志
-XX:+PrintGCDetails // 创建详细的gc日志

-XX:+PrintGCTimeStamps

-Xloggc:/export/Logs/com/gc.log // gc日志文件名

-XX:+UseGCLogFileRotation // 限制保存在gc日志中的数据量

-XX:GCLogFileSize=10M // 日志文件大小

-XX:NumberOfGCLogFiles=10 // 日志文件个数

-XX:+HeapDumpAfterFullGC // fullgc前dump文件保存

-XX:HeapDumpPath=/export/Logs/com/fgcdump.log // dump文件保存路径

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=目录 // oom时生成dump文件

// ================================= 附加参数如下 =============================================

// 可以使用-XX:DisableExplicitGC选项禁用显示调用Full gc（system.gc在cms gc下我们通过-XX:+ExplicitGCInvokesConcurrent来做一次稍微高效点的GC(效果比Full GC要好些)）

-XX:+UnlockExperimentalVMOptions // 解锁实验参数，允许使用实验性参数，JVM中有些参数不能通过-XX直接复制需要先解锁，比如要使用某些参数的时候，可能不会生效，需要设置这个参数来解锁 -XX:+UseParNewGC // 真正的并发收集器，与CMS搭配使用（ParNew收集器是Serial收集器的多线程版本，使用这个参数后会在新生代进行并行回收，老年代仍旧使用串行回收。新生代S区任然使用复制算法） -XX:+UseConcMarkSweepGC // 和应用程序线程一起执行，相对于Stop The World来说虚拟机停顿时间较少。停顿减少，吞吐量会降低。它使用的是 标记清除算法，运作过程为四个步骤，分别是 初始标记—并发标识—重新标记—并发清除。它是老年代的收集算法，新生代使用ParNew收集算法。默认关闭

CMS收集器的缺点是对服务器CPU资源较为敏感，在并发标记时会降低吞吐量。它使用的标记清除算法也会产生大量空间碎片，空间碎片的存在会加大Full GC的频率，虽然老年代还有足够的内存，但是因为内存空间不连续，不得不进行Full GC -XX:CMSInitiatingOccupancyFraction=75 // 允许最大占用占用率 -XX:+UseCMSInitiatingOccupancyOnly // 只用设定的回收阈值,如果不指定,JVM仅在第一次使用设定值,后续则自动调整 -XX:+ExplicitGCInvokesConcurrent // ExplicitGCInvokesConcurrent这个参数是配合CMS使用的，开启后System.gc()还是会触发Full GC，不过并不是一个完全的stop-the-world的Full GC，而是并发的CMS GC -XX:+ParallelRefProcEnabled // 可以用来并行处理 Reference，以加快处理速度，缩短耗时 -XX:+CMSParallelRemarkEnabled // 在CMS GC前启动一次ygc，目的在于减少old gen对ygc gen的引用，降低remark时的开销-----一般CMS的GC耗时 80%都在remark阶段

// 切记以下参数不要乱加

-XX:+UseCMSCompactAtFullCollection // Full GC后，进行一次整理，整理过程是独占的，会引起停顿时间变长。仅在使用CMS收集器时生效。

-XX:CMSFullGCsBeforeCompaction // 默认为 0，就是每次FullGC都对老年代进行碎片整理压缩，建议保持默认

2、 gc日志指标
S0: 新生代中Survivor space 0区已使用空间的百分比

S1: 新生代中Survivor space 1区已使用空间的百分比 E: 新生代已使用空间的百分比 O: 老年代已使用空间的百分比 M: 元空间已使用空间的百分比

CCS: 压缩类空间利用率百分比 YGC: 从应用程序启动到当前，发生Yang GC 的次数

YGCT: 从应用程序启动到当前，Yang GC所用的时间【单位秒】 FGC: 从应用程序启动到当前，发生Full GC的次数 FGCT: 从应用程序启动到当前，Full GC所用的时间 GCT: 从应用程序启动到当前，用于垃圾回收的总时间【单位秒】

3、 最大线程数
系统可创建最大线程数 = （机器本身可用内存 - JVM分配的堆内存 - JVM元数据区）/ 线程栈大小

4、 内存分析
4.1 常用命令
4.1.1 jstack

// Java堆栈跟踪工具，它用于打印出给定的java进程ID、core file、远程调试服务的Java堆栈信息.

jstack命令用于生成虚拟机当前时刻的线程快照线程快照是当前虚拟机内每一条线程正在执行的方法堆栈的集合，使用其主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致长时间等待等问题线程出现停顿的时候通过jstack来查看线程的调用堆栈，就可以知道没有响应的线程到底在做什么事，或者等待什么资源若java程序崩溃生成core文件，jstack可用来获得core文件的java stack和native stack的信息

还可附属到正在运行的java程序上，看到当前运行的java程序的java stack和native stack信息，若呈现hung状态，jstack很有用

应用：jstack [option] // 打印某个进程的堆栈信息

•线程状态

•Monitor监视锁

item1：实战案例1 jstack分析死锁问题

死锁指的是两个或两个以上的线程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，将无法继续进行

jps：终端中输入jsp查看当前运行的java程序

8896

5684 JUnitStarter

17836 Jps

19804 Launcher

文件分析：【本文件未死锁，仅用于分析，死锁时会出现 线程1持有A等B，线程2持有B等A】

"consumer_monitor_report_tp_pre_1_1_3_1677132947525" #7851 daemon prio=5 os_prio=0 tid=0x00007f8d2001b000 nid=0x31c8c waiting on condition [0x00007f8ceeeef000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000fad6df60> (a java.util.concurrent.CountDownLatch$Sync) ... Locked ownable synchronizers: - None

// consumer_monitor_report_tp_pre_1_1_3_1677132947525 的线程处于TIMED_WAITING状态，持有 - None 锁（无锁），等待 0x00000000fad6df60 的锁

item2：实战案例2 jstack分析cp过高问题

•通过 top 命令查看各个进程cpu使用情况，默认按cpu使用率高到低排序

•通过 top -Hp pid 查看该进程下，各个线程的cpu使用情况

•定位到cpu占用率高的线程之后，使用 jstack pid 命令查看当前java进程的堆栈状态

•nid=0x31c8b 进制转换，文件中，每个线程都有一个nid，查看状态

4.1.2 jstat

// java虚拟机统计信息工具，利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控

远程监控：jstat -gcutil port@ip

说明：GCT = YGCT + FGCT

4.1.3 jmap-histo

// 查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象

包括对 Heap size 和 垃圾回收状况的监控

num #instances #bytes class name ---------------------------------------------- 1: 3153872 297505208 [C 2: 214428 113791808 [B 3: 88856 81288672 [I 4: 3123084 74954016 java.lang.String 5: 520601 20824040 java.util.LinkedHashMap

Node; 11: 177935 5693920 java.util.HashMap

Node 18: 21894 2416424 java.lang.Class 19: 42925 2060400 java.util.HashMap 20: 55340 1770880 ​​java.io​​.ObjectStreamClass$WeakClassKey

4.1.4 jmqp-heap

// 查看进程堆内存使用情况，包括使用的GC算法、堆配置参数和各代中堆内存使用情况

using thread-local object allocation. Parallel GC with 2 thread(s)

Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 1073741824 (1024.0MB) NewSize = 402653184 (384.0MB) MaxNewSize = 402653184 (384.0MB) OldSize = 671088640 (640.0MB) NewRatio = 2 SurvivorRatio = 8 MetaspaceSize = 67108864 (64.0MB) CompressedClassSpaceSize = 1073741824 (1024.0MB) MaxMetaspaceSize = 17592186044415 MB G1HeapRegionSize = 0 (0.0MB)

Heap Usage: PS Young Generation Eden Space: capacity = 393216000 (375.0MB) used = 381729360 (364.0454864501953MB) free = 11486640 (10.954513549804688MB) 97.07879638671875% used From Space: capacity = 4718592 (4.5MB) used = 3489328 (3.3276824951171875MB) free = 1229264 (1.1723175048828125MB) 73.94849989149306% used To Space: capacity = 4718592 (4.5MB) used = 0 (0.0MB) free = 4718592 (4.5MB) 0.0% used PS Old Generation capacity = 671088640 (640.0MB) used = 633681304 (604.3255844116211MB) free = 37407336 (35.674415588378906MB) 94.4258725643158% used

49351 interned Strings occupying 4857128 bytes.

4.1.5 jmqp-dump

// 生成堆快照（瞬时）

利用jvisualvm分析内存dump文件：点击文件->装入->文件类型选“堆”



Visual VM的OQL语言是对HeapDump进行查询，类似于SQL的查询语言，它的基本语法如下：

select ] ]

OQL由3个部分组成：select子句、from子句和where子句。select子句指定查询结果要显示的内容。from子句指定查询范围，可指定类名，如java.lang.String、char[]、[​​Ljava.io​​.File;（File数组）。where子句用于指定查询条件。


4.2 加日志后
见调优方案

七、 调优方案1：增大新生代

1、 解析gc日志
元空间分配64M（不足自动调整了），新生代改为480m

•25.939: [Full GC (Metadata GC Threshold) [PSYoungGen: 4133K->0K(461312K)] [ParOldGen: 34773K->36327K(557056K)] 38907K->36327K(1018368K), [Metaspace: 62967K->62967K(1105920K)], 0.3564880 secs] [Times: user=0.72 sys=0.02, real=0.36 secs]

25.939

Full GC (Metadata GC Threshold)

GC (Allocation Failure)

GC (GCLocker Initiated GC)

PSYoungGen: 4133K->0K(461312K)

ParOldGen: 34773K->36327K(557056K)

38907K->36327K(1018368K)

Metaspace: 62967K->62967K(1105920K)

0.3564880 secs

user=0.72

sys=0.02

real=0.36 secs

容器已启动时间

发生一次 fgc（元空间不够用导致）

年轻代无足够空间

openJDK的一个bug，只是一直没被修复（​​https://bugs.openjdk.org/browse/JDK-8048556），不用过于关注​​

默认总容量为 0.9*新生代

数据变大因为新生代的垃圾进来了

GC前堆内存已使用容量→GC堆内存容量（堆内存总容量 = 0.9*新生代 + 老年代）

元空间未回收

整个GC花费时间

CPU工作在用户态时间

CPU工作在内核态时间

GC总时间


八、 调优方案2：增大元空间 + CMS & PNEW

以下方案暂时没啥问题


九、 临时方案以观后效

说明：去批量处理，降低对象大小，也许也是一个不错的方案，待验证。

-Xms1024m -Xmx1024m -Xmn480m -Xss512k -XX:MetaspaceSize=128m -XX:ParallelGCThreads=2 -XX:CICompilerCount=2 -XX:MaxDirectMemorySize=256m -XX:+UnlockExperimentalVMOptions -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+ExplicitGCInvokesConcurrent -XX:+ParallelRefProcEnabled -XX:+CMSParallelRemarkEnabled -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/export/Logs/xxx/gc.log -XX:GCLogFileSize=100M -XX:+HeapDumpAfterFullGC -XX:HeapDumpPath=/export/Logs/xxx/fgcdump.log


部署稳定后jvm监控图表如下：


ldquordquo收集器pxstrong老年代javaCMSJavaScript前端开发yyds干货盘点

有关“堆内存持续占用高 且 ygc回收效果不佳” 排查处理实践的更多相关文章

  1. ruby-on-rails - 使用 Ruby on Rails 进行自动化测试 - 最佳实践 - 2

    很好奇，就使用ruby​​onrails自动化单元测试而言，你们正在做什么？您是否创建了一个脚本来在cron中运行rake作业并将结果邮寄给您？git中的预提交Hook？只是手动调用？我完全理解测试，但想知道在错误发生之前捕获错误的最佳实践是什么。让我们理所当然地认为测试本身是完美无缺的，并且可以正常工作。下一步是什么以确保他们在正确的时间将可能有害的结果传达给您？ 最佳答案 不确定您到底想听什么，但是有几个级别的自动代码库控制:在处理某项功能时，您可以使用类似autotest的内容获得关于哪些有效，哪些无效的即时反馈。要确保您的提

  2. ruby-on-rails - Ruby net/ldap 模块中的内存泄漏 - 2

    作为我的Rails应用程序的一部分，我编写了一个小导入程序，它从我们的LDAP系统中吸取数据并将其塞入一个用户表中。不幸的是，与LDAP相关的代码在遍历我们的32K用户时泄漏了大量内存，我一直无法弄清楚如何解决这个问题。这个问题似乎在某种程度上与LDAP库有关，因为当我删除对LDAP内容的调用时，内存使用情况会很好地稳定下来。此外，不断增加的对象是Net::BER::BerIdentifiedString和Net::BER::BerIdentifiedArray，它们都是LDAP库的一部分。当我运行导入时，内存使用量最终达到超过1GB的峰值。如果问题存在，我需要找到一些方法来更正我的代

  3. ruby - 如何指定 Rack 处理程序 - 2

    Rackup通过Rack的默认处理程序成功运行任何Rack应用程序。例如:classRackAppdefcall(environment)['200',{'Content-Type'=>'text/html'},["Helloworld"]]endendrunRackApp.new但是当最后一行更改为使用Rack的内置CGI处理程序时，rackup给出“NoMethodErrorat/undefinedmethod`call'fornil:NilClass”:Rack::Handler::CGI.runRackApp.newRack的其他内置处理程序也提出了同样的反对意见。例如Rack

  4. ruby-on-rails - Ruby 中的内存模型 - 2

    ruby如何管理内存。例如:如果我们在执行过程中采用C程序，则以下是内存模型。类似于这个ruby如何处理内存。C:__________________|||stack|||------------------||||------------------|||||Heap|||||__________________|||data|__________________|text|__________________Ruby:? 最佳答案 Ruby中没有“内存”这样的东西。Class#allocate分配一个对象并返回该对象。这就是程序

  5. 叮咚买菜基于 Apache Doris 统一 OLAP 引擎的应用实践 - 2

    导读：随着叮咚买菜业务的发展，不同的业务场景对数据分析提出了不同的需求，他们希望引入一款实时OLAP数据库，构建一个灵活的多维实时查询和分析的平台，统一数据的接入和查询方案，解决各业务线对数据高效实时查询和精细化运营的需求。经过调研选型，最终引入ApacheDoris作为最终的OLAP分析引擎，Doris作为核心的OLAP引擎支持复杂地分析操作、提供多维的数据视图，在叮咚买菜数十个业务场景中广泛应用。作者｜叮咚买菜资深数据工程师韩青叮咚买菜创立于2017年5月，是一家专注美好食物的创业公司。叮咚买菜专注吃的事业，为满足更多人“想吃什么”而努力，通过美好食材的供应、美好滋味的开发以及美食品牌的孵

  6. jenkins部署1--jenkins+gitee持续集成 - 2

    前置步骤我们都操作完了，这篇开始介绍jenkins的集成。话不多说，看操作1、登录进入jenkins后会让你选择安装插件，选择第一个默认的就行。安装完成后设置账号密码，重新登录。2、配置JDK和Git都需要执行路径，所以需要先把执行路径找到，先进入服务器的docker容器，2.1JDK的路径root@69eef9ee86cf:/usr/bin#echo$JAVA_HOME/usr/local/openjdk-82.2Git的路径root@69eef9ee86cf:/#whichgit/usr/bin/git3、先配置JDK和Git。点击：ManageJenkins>>GlobalToolCon

  7. ruby-on-rails - Rails 中同一个类的多个关联的最佳实践？ - 2

    我认为我的问题最好用一个例子来描述。假设我有一个名为“Thing”的简单模型，它有一些简单数据类型的属性。像...Thing-foo:string-goo:string-bar:int这并不难。数据库表将包含具有这三个属性的三列，我可以使用@thing.foo或@thing.bar之类的东西访问它们。但我要解决的问题是当“foo”或“goo”不再包含在简单数据类型中时会发生什么？假设foo和goo代表相同类型的对象。也就是说，它们都是“Whazit”的实例，只是数据不同。所以现在事情可能看起来像这样......Thing-bar:int但是现在有一个新的模型叫做“Whazit”，看起来

  8. ruby-on-rails - 向 Rails 3 添加 Ruby 扩展方法的最佳实践？ - 2

    我有一个要在我的Rails3项目中使用的数组扩展方法。它应该住在哪里？我有一个应用程序/类，我最初把它放在(array_extensions.rb)中，在我的config/application.rb中我加载路径:config.autoload_paths+=%W(#{Rails.root}/应用程序/类)。但是，当我转到railsconsole时，未加载扩展。是否有一个预定义的位置可以放置我的Rails3扩展方法？或者，一种预先定义的方式来添加它们？我知道Rails有自己的数组扩展方法。我应该将我的添加到active_support/core_ext/array/conversion

  9. 键删除后 ruby​​ 哈希内存泄漏 - 2

    你好，我无法成功如何在散列中删除key后释放内存。当我从哈希中删除键时，内存不会释放，也不会在手动调用GC.start后释放。当从Hash中删除键并且这些对象在某处泄漏时，这是预期的行为还是GC不释放内存？如何在Ruby中删除Hash中的键并在内存中取消分配它？例子:irb(main):001:0>`ps-orss=-p#{Process.pid}`.to_i=>4748irb(main):002:0>a={}=>{}irb(main):003:0>1000000.times{|i|a[i]="test#{i}"}=>1000000irb(main):004:0>`ps-orss=-p

  10. Ruby-vips 图像处理库。有什么好的使用示例吗？ - 2

    我对图像处理完全陌生。我对JPEG内部是什么以及它是如何工作一无所知。我想知道，是否可以在某处找到执行以下简单操作的ruby​​代码:打开jpeg文件。遍历每个像素并将其颜色设置为fx绿色。将结果写入另一个文件。我对如何使用ruby​​-vips库实现这一点特别感兴趣https://github.com/ender672/ruby-vips我的目标-学习如何使用ruby​​-vips执行基本的图像处理操作(Gamma校正、亮度、色调……)任何指向比“helloworld”更复杂的工作示例的链接——比如ruby​​-vips的github页面上的链接，我们将不胜感激!如果有ruby​​-

随机推荐