1. 红孩笔记首页
  2. Java

Slowness in Java Application Due To Increased FullGC Events: G1GC

• Java • 阅读 4253

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)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
910
上一篇 2022年5月1日 20:52
下一篇 2022年5月1日 20:53

相关推荐

  • The JVM Architecture Explained Java

    The JVM Architecture Explained

    Every Java developer knows that bytecode will be executed by the JRE (Java Runtime Environment). But many don’t know the fact that JRE is the implementation of Java Virtual M…

    2022年5月1日
    51530
  • Java压缩zip文件存在文件或者目录乱码问题，压缩过滤乱码文件 Java

    Java压缩zip文件存在文件或者目录乱码问题，压缩过滤乱码文件

    平时工作中有时候遇到要压缩的文件里面存在乱码，但是又不能一时半会儿能解决的。目前给临时的方案，在压缩的时候把乱码过滤掉，如果不过滤。通过Java来压缩或者解压的适合可能存在问题。 代码如下： package cn.utils; import java.io.File; import java.io.FileInputStream; import java.i…

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

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

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

    2022年5月2日
    7.3K9770
  • Java操作SFTP工具类，文件上传下载删除，获取列表目录 Java

    Java操作SFTP工具类，文件上传下载删除，获取列表目录

    Java操作SFTP工具类，文件上传下载删除，获取列表目录 需要依赖的Maven包 <!– SFTP –> <dependency> <groupId>com.jcraft</groupId> <artifactId>jsch</artifactId> <version>…

    2022年6月1日
    827770

  • Spring Cloud Alibaba版本对应关系

    版本依赖关系(推荐使用) 由于 Spring Boot 2.4+ 和以下版本之间变化较大，目前企业级客户老项目相关 Spring Boot 版本仍停留在 Spring Boot 2.4 以下，为了同时满足存量用户和新用户不同需求，社区以 Spring Boot 2.4 为分界线，同时维护 2.2.x 和 2021.x 两个分支迭代。 2021.x 分支 适配…

    Java 2022年6月28日
    11.7K30680

发表回复

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

评论列表（910条）