1. 红孩笔记首页
  2. Java

Slowness in Java Application Due To Increased FullGC Events: G1GC

• Java • 阅读 9970

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

相关推荐

  • 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日
    14.0K32920
  • Java压缩zip文件存在文件或者目录乱码问题，压缩过滤乱码文件 Java

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

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

    2022年7月14日
    7.6K16020

  • OOM专题-String 和 StringBuilder的最大可用长度是多少

    String 直接量 超出 65535之后（127KB），IDEA 编译器会报错，因为 直接量是存储在常量池，常量池的定义规定中 有长度限制 2e16 。 String在运行期间的拼接后的最大长度是 int 的最大值 。 StringBuilder 长度是 int 的最大值 2e32 ，21亿 个字符，42亿字节 Byte= 大小4G。 超出长度的需要 用文…

    Java 2022年7月5日
    1.2K560
  • 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日
    65940
  • eclipse 运行 Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory Java

    eclipse 运行 Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory

    java 运行报异常：Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000794500000, 576716800, 0) failed; error=’Cannot allocate memory’ (errno=12) 原因：因为配…

    2022年7月27日
    1.8K2530

回复 vivod iz zapoya sochi_szet

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

评论列表（2,587条）