1. 红孩笔记首页
  2. Java

Slowness in Java Application Due To Increased FullGC Events: G1GC

• Java • 阅读 9963

In this blog, we will see one of the issues and solutions which I found in one of our production servers: our Java application became slow due to more GC pauses.  I will explain a particular approach that can be one of the reasons for initiating more GC pauses.

To understand this article, one must have basic knowledge of the G1GC algorithm of Java for garbage collection. Don’t worry if you don’t have knowledge of G1GC: I will write other articles on the basics of G1GC later, and then you can read this article again. 

Let’s start with the issue we are facing: applications become unresponsive very frequently. 

Analysis  

  • After debugging JVM level stats from JMX bean dumping, it was clear that GC collection time was greatly increased in between.
  • Heap also increasing 

After that, we enabled GC log by using -Xlog:gc=debug:file=/tmp/gc.log in JVM arguments while starting the application. 

Upon analyzing gc.log, we found that full GC is triggered many times. Additionally, whenever full GC triggers, it generally stops the application for some time. In the Java language, we call this STW (Stop the World). 

Generally there are the following type of events in G1GC: 

  • Minor: Eden + Survivor From -> Survivor To
  • Mixed: Minor + (# reclaimable Tenured regions / -XX:G1MixedGCCountTarget) regions of Tenured
  • Full GC: All regions evacuated
  • Minor/Mixed + To-space exhaustion: Minor/Mixed + rollback + Full GC

In a smoothly running application, only batches of minor events alternating with batches of mixed events should be there. Full GC events and to-space exhaustion are things you absolutely don’t want to see when running G1GC. They need to be detected and eliminated, and if they are running, they should be run by some external events such as jstack, jmap, etc.

For in-depth details of these events, as already stated, I will make a blog series explaining G1GC concepts. For now, you can do an independent search. 

Now, let’s get back to our debugging.

We checked that no external command for taking a thread dump, heap dump, or histogram was made that can possibly initiate a Full GC event. The question now is: why is this full GC triggering Upon further research, we found that humongous objects can be one of the reasons for triggering the Full GC event. 

Now, what are humongous objects?

A brief definition is: any single data allocation ≥ G1HeapRegionSize/2 is considered a humongous object, which is allocated out of contiguous regions of free space, which are then added to tenured. As humongous objects are allocated out of free space, allocation failures trigger GC events. If an allocation failure from free space triggers GC, the GC event will be a Full GC, which is very undesirable in most circumstances. To avoid Full GC events in an application with lots of humongous objects, one must ensure the free space pool is large enough as compared to Eden so that Eden will always fill up first. 

So we started checking if our application is generating humongous objects, and from gc.log, we found that lots of humongous objects are created. These were the reasons for triggering Full GC events. 

Commands for Humongous Object Check

The following are commands to check the humongous objects, especially in Linux : 

Run the following command on your gc.log.

Command 1:

 
humoungous_humongoud_size.txt” data-lang=””> 

grep "source: concurrent humongous allocation" /tmp/gc.log | sed 's/.*allocation request: ([0-9]*) bytes.*/1/' > humoungous_humongoud_size.txt

Command 2:

  
awk -F',' '{sum+=$1} END{print sum;}' humoungous_humongoud_size.txt

This will give you the size of humongous objects generated in the application.

We have Java less than Oracle JDK 8u45 version. For Java greater than this, it is written in the release notes that these humongous objects also get collected in minor events. 

Search for: “G1 now collects unreachable Humongous objects during young collections” in the Release Notes JDK.

We upgraded our JDK, and the issue frequency was minimized too much as these objects are now not triggering any major event like FullGC. But one should also care about generating these large objects. We also checked and analyzed one of the heaps and corrected the code not to generate these big objects if unneeded. 

I hope this blog will be helpful.  Please comment and share!

文章来源于互联网:Slowness in Java Application Due To Increased FullGC Events: G1GC

发布者：小站，转转请注明出处：http://blog.gzcity.top/4157.html

赞 (1)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
2587
上一篇 2022年5月1日 20:52
下一篇 2022年5月1日 20:53

相关推荐

  • Android版本 (1.0~12.0) 与API Level (SDK版本1~32) 对应表

    什么是 API 级别？ API 级别是一个对 Android 平台版本提供的框架 API 修订版进行唯一标识的整数值。 Android 平台提供了一种框架 API，应用可利用它与底层 Android 系统进行交互。 该框架 API 由以下部分组成： 一组核心软件包和类 一组用于声明清单文件的 XML 元素和属性 一组用于声明和访问资源的 XML 元素和属性 …

    Java 2023年6月1日
    40.6K26220
  • Java复制文件&文件夹工具类 Java

    Java复制文件&文件夹工具类

    Java复制文件&文件夹工具类 package cn.utils; import java.io.*; /** * 复制文件夹 * */ public class CopyDirUtil { /** * 复制文件夹 * * @param resource 源路径 * @param target 目标路径 */ public static void c…

    2022年6月17日
    25.8K52000
  • Java性能调优：优化正则表达式的匹配效率 Java

    Java性能调优：优化正则表达式的匹配效率

    在我们的日常业务开发中经常会涉及到使用正则表达式对数据进行处理，比如String的Split()方法，它根据方法中传入的正则表达式对字符串做分割处理。 但是我们是否真的了解正则表达式，它是如何匹配的？不同的匹配方式会带来怎样的效率差别？怎样才能做到效率最优？ 本篇就对“如何优化正则表达式的匹配效率？”做深入探讨。   一、匹配的三种方式 看下面这个例子，我们…

    2022年7月6日
    74530
  • Java多线程方式快速解析大量文本内容得到pdf链接转换为文本-学习笔记 Java

    Java多线程方式快速解析大量文本内容得到pdf链接转换为文本-学习笔记

    Java多线程方式快速解析大量文本内容得到pdf链接转换为文本-学习笔记 解析流程： 1、一个目录里面包含大量多种格式文件；2、从目录中提取txt为后缀的文件路径List；3、根据服务器性能设定多线程处理文本数量；4、txt文本中获取所有的链接；5、通过正则提取后缀为.pdf链接；6、下载pdf文件到本地；7、使用开源工具把pdf转换为txt内容；获取链接正…

    2022年5月2日
    9.1K11850
  • 将本地jar包上传至Nexus Java

    将本地jar包上传至Nexus

    其实上传jar包到Nexus有好几种方法，这里先来介绍一种比较简单的方法： 1.首先登陆私服： 2.点击左边“Repositories”，选中“3rd party” 上传本地jar包(第五步可根据需要自行修改)： 2.点击头部Refresh按钮，检查是否上传成功，如下图表示上传成功： 4.本地pom.xml文件添加依赖： <dependency>…

    2022年5月16日
    14.7K26940

回复 DavidLiery

您的邮箱地址不会被公开。 必填项已用 * 标注

评论列表（2,587条）