1. 红孩笔记首页
  2. Java

Slowness in Java Application Due To Increased FullGC Events: G1GC

• Java • 阅读 9944

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

相关推荐

  • 【云原生】Spring Cloud微服务学习路线汇总 Java

    【云原生】Spring Cloud微服务学习路线汇总

    Spring Cloud是什么？简单来说Spring Cloud是一系列框架的组成集合。主要利用的我们现在主流应用的Spring Boot框架开发便利性、巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以利用Spring Boot的开发风格做到一键启动和部署。Spring Cloud没有重复制造轮子…

    2022年6月24日
    831670
  • Java操作SFTP工具类，文件上传下载删除，获取列表目录 Java

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

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

    2022年6月1日
    1.5K840
  • 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

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

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

    Java 2022年7月5日
    1.2K560

  • 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

回复 pill

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

评论列表（2,585条）