垃圾回收G1日志解析

最新推荐文章于 2024-08-09 19:03:45 发布
最新推荐文章于 2024-08-09 19:03:45 发布
阅读量559 收藏
点赞数
文章标签： 大数据 java
原文链接：http://www.cnblogs.com/geektcp/p/9951539.html
版权

G1垃圾回收器介绍

首先要搞清楚G1垃圾回收的过程

主要分为下面4个步骤：

初始标记（Initial Marking）           由于常规标记对象是否直接关联到GC roots，过程简单，停顿时间短

并发标记（Concurrent Marking） 由于可达性性分析，存在较长停顿

最终标记（Final Marking）           由于把并发标记时漏掉的那部分垃圾内存标记起来，比较少，停顿时间短

筛选回收（Live Data Couting and Evacuation）  对标记后的垃圾内存进行整理，按指定计划进行回收。

 

在下面的案例中，红色部分明确标明了这4个阶段。

 

 

 G1垃圾收集器参数说明

以我的spark参数为例：

spark.executor.extraJavaOptions -Dtag=mobius.optimize -XX:+UseG1GC -XX:+PrintFlagsFinal -XX:+PrintReferenceGC -XX:+PrintGCDetails

-XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps-XX:+PrintAdaptiveSizePolicy -XX:+PrintGC -Xloggc:/tmp/spark.gc.log

-XX:+UnlockDiagnosticVMOptions -XX:+G1SummarizeConcMark -XX:InitiatingHeapOccupancyPercent=35 -XX:ConcGCThreads=15

-XX:+PrintGCApplicationConcurrentTime -XX:-UseGCOverheadLimit

 

下面是其拆分后的注释：

spark.executor.extraJavaOptions \    传入java参数给spark各个excutor

-Dtag=mobius.optimize \　　　　　　标记名

-XX:+UseG1GC \　　　　　　　　　指定垃圾收集器

-XX:+PrintFlagsFinal \　　　　　　　java对象引用分为四种：强引用FinalReference，软引用SoftReference，弱引用WeakReference，虚引用PhantomReference。一般都是强引用，比如new一个对象并赋值

-XX:+PrintReferenceGC \　　　　　打印垃圾对象的引用数量

-XX:+PrintGCDetails \　　　　　　　 打印详细GC日志

-XX:+PrintGCDateStamps \　　　　 打印可读的日期时间戳 比如2018-11-12

-XX:+PrintGCTimeStamps \　　　　打印可读的时间戳 比如 09:10:11

-XX:+PrintAdaptiveSizePolicy \         启用自适应大小（为了避免fullGC，允许改变eden空间和survivor空间大小）

-XX:+PrintGC \　　　　　　　　　　打印GC日志

-Xloggc:/tmp/spark.gc.log \　　　　   指定GC日志路径

-XX:+UnlockDiagnosticVMOptions \

-XX:+G1SummarizeConcMark \         

-XX:InitiatingHeapOccupancyPercent=35 \

-XX:ParallelGCThreads=33 \　　　　　　 Parallel和G1收集器的标记阶段的线程数l量，默认33，对应GC日志 [ GC Workers: 33 ]（并行：多个垃圾收集线程并行工作，此时用户线程处于等待状态，stop the world）

-XX:ConcGCThreads=15 \　　　　　　     CMS和G1回收器的前三个标记阶段都是多线程的，指定GC并发线程数量，默认0（并发：用户线程与垃圾收集线程同时执行，不一定是并行，可能会交替执行）

-XX:+PrintGCApplicationConcurrentTime \         打印应用程序执行时间

-XX:-UseGCOverheadLimit \　　　　　       　  取消垃圾回收时的内存限制（减号）

-XX:MaxGCPauseMillis=200　　　　  　　　　垃圾回收停顿最长时间，默认是200ms

 

 

日志分析案例

下面一段日志是我在spark计算任务中产生的垃圾回收日志：

2018-11-13T05:32:44.473+0800: 1.857: Application time: 0.2130324 seconds
2018-11-13T05:32:44.571+0800: 1.954: Application time: 0.0970449 seconds
2018-11-13T05:32:44.696+0800: 2.079: Application time: 0.1249397 seconds
2018-11-13T05:32:44.874+0800: 2.258: Application time: 0.1776871 seconds
 2.258: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: requested by GC cause, GC cause: Metadata GC Threshold]
 2.258: [G1Ergonomics (Concurrent Cycles) initiate concurrent cycle, reason: concurrent cycle initiation requested]
2018-11-13T05:32:44.875+0800: 2.259: [GC pause (Metadata GC Threshold) (young) (initial-mark) 2.260: 
[G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 0, predicted base time: 10.00 ms, 
remaining time: 190.00 ms, target pause time: 200.00 ms]
 2.260: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 60 regions, survivors: 0 regions, predicted young region time: 3605.71 ms]
 2.260: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 60 regions, survivors: 0 regions, old: 0 regions, 
predicted pause time: 3615.71 ms, target pause time: 200.00 ms]
2018-11-13T05:32:44.948+0800: 2.331: [SoftReference, 0 refs, 0.0002103 secs]2018-11-13T05:32:44.948+0800: 2.332: 
[WeakReference, 970 refs, 0.0005817 secs]2018-11-13T05:32:44.949+0800: 2.332: [FinalReference, 4265 refs, 0.0266394 secs]
2018-11-13T05:32:44.975+0800: 2.359: [PhantomReference, 0 refs, 3 refs, 0.0000585 secs]2018-11-13T05:32:44.976+0800: 2.359: 
[JNI Weak Reference, 0.0001374 secs], 0.1040572 secs]
   [Parallel Time: 29.1 ms, GC Workers: 33]
      [GC Worker Start (ms): Min: 2260.1, Avg: 2265.0, Max: 2265.9, Diff: 5.8]
      [Ext Root Scanning (ms): Min: 0.2, Avg: 18.2, Max: 22.7, Diff: 22.5, Sum: 691.2]
      [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
         [Processed Buffers: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.3]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.3, Max: 8.6, Diff: 8.6, Sum: 10.0]
      [Object Copy (ms): Min: 0.0, Avg: 3.9, Max: 22.9, Diff: 22.9, Sum: 147.1]
      [Termination (ms): Min: 0.0, Avg: 1.3, Max: 2.3, Diff: 2.3, Sum: 50.3]
         [Termination Attempts: Min: 1, Avg: 3.0, Max: 17, Diff: 16, Sum: 115]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 1.6]
      [GC Worker Total (ms): Min: 22.7, Avg: 23.7, Max: 28.6, Diff: 5.9, Sum: 900.6]
      [GC Worker End (ms): Min: 2288.6, Avg: 2288.7, Max: 2288.8, Diff: 0.2]
   [Code Root Fixup: 1.0 ms]
   [Code Root Purge: 0.1 ms]
   [Clear CT: 1.0 ms]
   [Other: 72.8 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 68.9 ms]
      [Ref Enq: 0.2 ms]
      [Redirty Cards: 0.4 ms]
      [Humongous Register: 0.1 ms]
      [Humongous Reclaim: 0.1 ms]
      [Free CSet: 0.5 ms]
   [Eden: 240.0M(512.0M)->0.0B(496.0M) Survivors: 0.0B->16.0M Heap: 254.0M(10.0G)->31.7M(10.0G)]
 [Times: user=0.44 sys=0.09, real=0.11 secs]
2018-11-13T05:32:44.980+0800: 2.363: [GC concurrent-root-region-scan-start]
2018-11-13T05:32:44.996+0800: 2.380: [GC concurrent-root-region-scan-end, 0.0167701 secs]
2018-11-13T05:32:44.996+0800: 2.380: [GC concurrent-mark-start]
2018-11-13T05:32:45.013+0800: 2.396: [GC concurrent-mark-end, 0.0160995 secs]
2018-11-13T05:32:45.013+0800: 2.396: Application time: 0.0328728 seconds
2018-11-13T05:32:45.013+0800: 2.397: [GC remark 2018-11-13T05:32:45.013+0800: 2.397: 
[Finalize Marking, 0.0331140 secs] 2018-11-13T05:32:45.047+0800: 2.430: 
[GC ref-proc2018-11-13T05:32:45.047+0800: 2.430: 
[SoftReference, 0 refs, 0.0001959 secs]2018-11-13T05:32:45.047+0800: 2.430: 
[WeakReference, 0 refs, 0.0001148 secs]2018-11-13T05:32:45.047+0800: 2.430: 
[FinalReference, 0 refs, 0.0001158 secs]2018-11-13T05:32:45.047+0800: 2.430: 
[PhantomReference, 0 refs, 0 refs, 0.0002233 secs]2018-11-13T05:32:45.047+0800: 2.431: 
[JNI Weak Reference, 0.0000572 secs], 0.0008127 secs] 2018-11-13T05:32:45.047+0800: 2.431: [Unloading, 0.0078450 secs], 0.0442183 secs]
 [Times: user=0.36 sys=0.01, real=0.05 secs]
2018-11-13T05:32:45.058+0800: 2.441: Application time: 0.0001231 seconds
2018-11-13T05:32:45.058+0800: 2.442: [GC cleanup 35M->35M(10G), 0.0134109 secs]
 [Times: user=0.04 sys=0.00, real=0.01 secs]
2018-11-13T05:32:45.144+0800: 2.528: Application time: 0.0721037 seconds
2018-11-13T05:32:45.392+0800: 2.775: Application time: 0.2464978 seconds
2018-11-13T05:32:45.805+0800: 3.188: Application time: 0.4129881 seconds
2018-11-13T05:32:46.806+0800: 4.190: Application time: 1.0001058 seconds
下面是每条日志含义解析：
Application time： 应用程序时间
。。。

 

转载于:https://www.cnblogs.com/geektcp/p/9951539.html

dianfuwo9488
关注
JVM虚拟机：G1垃圾回收器的日志分析
huanfeng_AI的博客
11-25 811
本文我们将学习G1垃圾回收器的日志。
G1垃圾回收日志分析
齐梦星空
10-09 1282
标准 gc 日志 使用G1垃圾回收器最难的地方是读懂回收日志。G1回收虽然也是分代的，但是打印出来的日志却不像其他回收器那样明显。所以需要好好配置JVM参数才行。先看下面一段日志，这段日志是通过配置好的JVM参数输出的，分隔明确，很容易分辨出每次回收过程。 # 每次回收以 花括号开始 # invocations=2302 代表第2302次回收 {Heap before GC invocations=2302 (full 0): garbage-first heap total 32768K, u
理解G1垃圾回收日志
weixin_30612769的博客
09-21 174
本篇文章主要介绍在-XX:+PrintGCDetails选项的情况下G1 GC log打印的信息。（注：本文假设读者对G1算法的基本原理已经有所了解） 下面是一段G1垃圾收集器相关的log信息 0.522: [GC pause (young), 0.15877971 secs] [Parallel Time: 157.1 ms] [GC Worker Start (ms)...
8. G1垃圾收集日志
wwww641788662的博客
03-20 377
1 G1 垃圾收集日志 1.1 垃圾收集器设置 设置 JVM 启动参数-XX:+UseG1GC，将当前 JVM 增加回收器设置为 G1 垃圾收集器，启动参数可参考使用-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:D://l...
G1垃圾回收器日志格式
奔跑的蜗牛
02-09 1935
摘要: 由于 G1 GC 正在逐渐成为 JVM 默认的垃圾收集器，它的使用与关注度也会逐渐增加，本文主要介绍如何理解 G1 GC 的日志格式。在 Java9 中，G1 GC 将成为默认的垃圾收集器，G1 垃圾收集器的关键特性之一是能够在不牺牲吞吐量的同时，限制 GC 暂停时间(即可以设置所需的最大停顿时间)。由于 G1 GC 正在逐渐成为默认的垃圾收集器，它的使用与关注度也会逐渐增加。因此在调整 ...
最详细G1垃圾回收器日志解读
齐梦星空
01-28 1477
首先，开启gc日志。-XX:+PrintGCDetails 疏散阶段 疏散阶段，主要是将内存中的数据从一些分区复制到其他分区 0.522: [GC pause (young), 0.15877971 secs] # 这次疏散只涉及年轻代，总耗时 0.15877971.如果是混合gc则可能是 [GC pause (mixed), 0.32714353 secs] [Parallel Time: 157.1 ms] # 并行疏散，总耗时 157.1 ms [GC Worker Start (m
【HDFS垃圾回收机制深度解析】：回收站工作的秘密与数据恢复步骤
[【HDFS垃圾回收机制深度解析】：回收站工作的秘密与数据恢复步骤](https://uploads-ssl.webflow.com/621b496f53d9ed80011a698a/62387627056ce431f59d0f39_trashinhadoop.png) # 1. HDFS垃圾回收机制概述 Hadoop...
【C编译器内存与垃圾回收】：高效管理机制全解析，性能优化的关键一步
[【C编译器内存与垃圾回收】：高效管理机制全解析，性能优化的关键一步](https://www.secquest.co.uk/wp-content/uploads/2023/12/Screenshot_from_2023-05-09_12-25-43.png) # 1. C编译器内存管理概述 ## 1.1 内存...
JVM之垃圾回收和调优思路
星星都没我亮的博客
11-03 1664
文章目录GC的基础知识1.什么是垃圾2.如何定位（找到）垃圾3.常见的垃圾回收算法4.JVM内存分代模型（用于分代垃圾回收算法）5.常见的垃圾回收器常见垃圾回收器组合参数设定：(1.8)JVM调优第一步，了解JVM常用命令行参数PS GC日志详解调优前的基础概念：什么是调优？调优，从规划开始优化环境解决JVM运行中的问题一个案例理解常用工具jconsole远程连接jvisualvm远程连接jprofiler (收费)arthas在线排查工具GC算法的基础概念CMSCMS的问题CMS日志分析G1G1日志详解案
g1垃圾收集器gc的四种日志解释
J_Lee
11-16 1082
g1垃圾收集器gc的四种日志解释
理解G1垃圾收集器日志
zhanggang807的专栏
05-27 8298
理解G1垃圾收集器日志 发表这个文章的目的是为了解释使用了G1垃圾收集器的一些跟踪和诊断选项而生成出来的垃圾收集日志的意义。我们来看一下使用一个提供最详细的信息级别的生产环境选项PrintGCDetails生成的输出日志。同时，我们也会看一下启用的两个诊断选项 -XX:+UnlockDiagnosticVMOptions 、 -XX:G1PrintRegionLivenessInfo 的输出
Java虚拟机2 G1垃圾回收详解， 参数， 日志
c39660570的博客
05-27 792
垃圾回收（GC）算法 哪些对象需要被回收？ 引用计数 可达性分析 回收垃圾对象 标记清除 Mark-Sweep 标记复制 Mark-Copy 标记整理 Mark-Compact 分代收集 新生代、老年代 并行与并发 其他GC概念 根节点 安全点 记忆集 写屏障/读屏障 三色标记法 分配内存 指针碰撞 空闲链表 G1 垃圾回收（Garbage-First） 堆内存 G1采用分代回收，将整个堆拆成多个分区（Heap Region），一次只回收部分分区。一个分区既可以充当新生代可也以充当老年代。 G1的分
JVM 不同垃圾回收器的日志格式分析
tian830937的专栏
03-02 781
jvm 垃圾回收器的日志分析
JVM 性能分析 —— G1 日志分析
最新发布
longool的博客
08-09 1380
文章目录日志级别-XX:+PrintGC（简洁版）-XX:+PrintGCDetails（详细版）-XX:G1LogLevel=finest（非常详细版）YGC 日志并发标记日志Mixed GC 日志Full GC 日志 日志级别 JVM 日志级别中的 fine、finer 和 finest 这三个级别 fine：JVM 配置参数为 -XX:G1LogLevel=fine 或使用 -XX:+PrintGC。 用于输出一些常规性的信息，不会产生太多的日志输出。 finer：JVM 配置参数为 -XX:
JVM 垃圾回收器(下)
m0_54202121的博客
04-19 379
文章目录⑦G1回收器：区域化分代式Garbage First（G1）横空出世的原因？Garbage First(G1)由来G1参数设置G1收集器的常见操作步骤G1收集器的适用场景分区Region：化整为零Remembered Set（记忆集）G1垃圾回收器的回收过程G1回收过程-年轻代GCG1回收过程-并发标记过程G1回收过程 - 混合回收G1回收可选的过程 - Full GCG1回收的优化建议垃圾回收器总结垃圾收集器的组合关系怎么选择垃圾回收器GC日志分析verbose:gcPrintGCDetails补
JVM虚拟机（十二）ParallelGC、CMS、G1垃圾收集器的 GC 日志解析
ACGkaka的博客
04-22 1868
JVM虚拟机（十二）ParallelGC、CMS、G1垃圾收集器的 GC 日志解析
JVM性能——开启回收日志和实时查看GC信息
大风的博客
11-01 5278
如何开启GC日志和分析日志
spark-调优-JVM
program哲学
09-21 849
开启日志调试 在让G1 GC跑起来之后，我们下一步就是需要根据GC log，来进一步进行性能调优。首先，我们要让JVM记录比较详细的GC日志. 对于Spark而言，我们需要在SPARK_JAVA_OPTS中设置参数使得Spark保留下我们需要用到的日志. 一般而言，我们需要设置这样一串参数： -XX:+PrintFlagsFinal -XX:+PrintReferenceGC -verbos
java的垃圾回收浅谈
sinat_14913533的博客
12-16 1461
垃圾回收过程其实都包含两步：标记+回收。综合来看，复制算法适合在垃圾回收执行时存活对象比较少的场景；整理算法适合在垃圾回收时存活对象较多但是不能有内存碎片的场景；而清理算法因为会产品内存碎片，实际的场景其实并不多，CMS使用该算法，但也诟病比较多。对于一个java进程中的对象，经过统计发现，大部分对象生命期都是比较短的，活不过一次垃圾回收，而少部分生命期比较长，多次gc后依然存在，甚至和java进程生命期相同。针对这种情况，就对java的内存进行了分区，不同分区使用不同的回收算法，来达到最大的收集效果。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值