记录一次JVM调优过程4-优快云博客

本文链接：https://blog.youkuaiyun.com/AnalogElectronic/article/details/148585195

记录一次JVM调优过程4

当前yaml配置

resources:
    limits:
      cpu: 500m
      memory: 7Gi
    requests:
      cpu: 300m
      memory: 6Gi

CKE容器内存使用率告警，主机:的内存使用率达到98

bash-4.4# jmap -heap 1
Attaching to process ID 1, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.161-b12

using thread-local object allocation.
Parallel GC with 33 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 32210157568 (30718.0MB)
   NewSize                  = 715653120 (682.5MB)
   MaxNewSize               = 10736369664 (10239.0MB)
   OldSize                  = 1431830528 (1365.5MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 5143265280 (4905.0MB)
   used     = 4600946960 (4387.804946899414MB)
   free     = 542318320 (517.1950531005859MB)
   89.45575834657318% used
From Space:
   capacity = 926941184 (884.0MB)
   used     = 11290448 (10.767410278320312MB)
   free     = 915650736 (873.2325897216797MB)
   1.2180328369140625% used
To Space:
   capacity = 1017118720 (970.0MB)
   used     = 0 (0.0MB)
   free     = 1017118720 (970.0MB)
   0.0% used
PS Old Generation
   capacity = 3605004288 (3438.0MB)
   used     = 1926078144 (1836.8512573242188MB)
   free     = 1678926144 (1601.1487426757812MB)
   53.427901609197754% used

bash-4.4# jstat -gcutil 1
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  1.22   0.00  89.46  53.43  90.11  85.67    148  260.891    10  452.156  713.047

bash-4.4# jstat -gcmetacapacity 1
   MCMN       MCMX        MC       CCSMN      CCSMX       CCSC     YGC   FGC    FGCT     GCT
       0.0  1200128.0   169896.0        0.0  1048576.0    19112.0   148    10  452.156  713.047

bash-4.4# java -version
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)

当前dockerFile jvm参数如下，根据以上信息还有调优的空间吗？

ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar","--spring.profiles.active=pro"]

用户的问题是让我详细解释一个 ENTRYPOINT 中的 JVM 参数设置，并说明为什么这样设置。从这个需求来看，用户的意图很明确：他们需要对这些参数的作用和调优背景有更深入的理解。这可能是因为他们在尝试优化 JVM 的性能，或者在解决一些与内存、GC 相关的问题，比如高内存使用率、频繁的 GC 停顿等。
首先，我需要分析这些参数的具体作用。每个参数背后都有特定的功能和意义，比如 -XX:+UseG1GC 是关于垃圾回收器的选择，-XX:MaxGCPauseMillis 是关于 GC 停顿时间的控制，-Xms 和 -Xmx 是关于堆内存的初始化和最大值设置。这些参数的作用相对独立，但也存在关联，比如选择 G1GC 后，-XX:MaxGCPauseMillis 和 -XX:InitialHeapOccupancyPercent 是为 G1GC 提供更精细化的调整。
其次，我需要结合用户提供的上下文，尤其是前面提到的 jmap 和 jstat 输出信息。这些信息帮助我理解当前的 JVM 状态，比如 Eden 区使用率高、GC 频繁、内存占用较大等。这些背景信息让我能更好地解释为什么需要这些参数调整，比如选择 G1GC 是为了减少 GC 停顿时间，调整堆内存大小是为了避免内存不足或浪费，设置 -XX:NewRatio 是为了优化新生代和老年代的分配比例。
然后，我需要规划回答的结构。用户的提问是关于参数的详细解释，所以我的回答应该逐个解析参数，并且明确它们的作用和调优目的。为了让回答更有逻辑性，我会按照参数在命令中的顺序逐一说明，同时结合上下文解释为什么这样设置。此外，我意识到用户可能希望看到一些对比和权衡，比如为什么选择 G1GC 而不是 Parallel GC，或者为什么调整 -XX:NewRatio。
在语气和风格上，我需要保持清晰、专业，同时避免过于技术化，确保用户能够理解。我会用简洁的语言解释技术细节，但不会省略关键内容。如果有需要，我会补充一些背景知识，比如 G1GC 的特点或者新生代的作用。
最后，我需要确保回答的完整性和连贯性。比如，我不能只解释参数的作用，却忽略了调优的背景和目标；也不能只提到参数的调优目标，却没有说明它们在当前上下文中的具体意义。总之，我的回答需要既全面又具体，同时与用户提供的信息紧密相关。

根据你提供的信息，确实还有一定的 JVM 参数调优空间。以下是目前情况的分析和调优建议：

当前情况分析

内存使用方面 ：从 jmap -heap 和 jstat -gcutil 的输出看，堆内存总容量为 30718MB，而当前实际使用量为 6224.656204226684MB（计算方式：Eden used+From used+To used+PS Old used），内存使用率约为 20.26%，看起来似乎还有较多空闲内存，但实际上 Eden 区使用率高达 89.46%，接近饱和，可能会频繁触发 Young GC。
GC 情况方面 ：Young GC 已经发生了 148 次，消耗时间 260.891 秒，Full GC 发生了 10 次，消耗时间 452.156 秒，GC 总耗时 713.047 秒，对应用性能有一定影响。
容器资源限制方面 ：当前 YAML 配置中，内存 limits 为 7Gi，requests 为 6Gi，从主机内存使用率达到 98% 来看，可能存在容器内存分配不合理或应用实际内存需求超出容器限制的问题。

调优建议

调整垃圾回收器及参数
- 选择合适的垃圾回收器 ：考虑到当前 Eden 区使用率高、GC 频繁的情况，可以尝试使用 G1 垃圾回收器来更好地控制停顿时间和吞吐量。在 Dockerfile 的 ENTRYPOINT 中添加 -XX:+UseG1GC 参数。
- 设置 G1GC 参数 ：如设置最大停顿时间目标 -XX:MaxGCPauseMillis=200，设置初始堆内存占用比例 -XX:InitialHeapOccupancyPercent=40，根据实际情况调整这些参数，以达到合适的 GC 效果。
调整堆内存大小
- 减少堆内存大小 ：根据主机内存使用情况和容器内存限制，适当减小 JVM 堆内存大小，使容器内存使用更加合理，避免主机内存过度使用。例如，可以将堆内存设置为 5Gi 左右，在 ENTRYPOINT 中添加 -Xms5G -Xmx5G 参数。
- 调整新生代和老年代比例 ：根据当前新生代使用情况，可以适当增加新生代大小，减少 Eden 区溢出到老年代的情况，降低 Full GC 频率。例如，设置 -XX:NewRatio=3，新生代占堆内存的 1/4。
增加容器内存限制
- 如果应用实际内存需求较大，且主机内存资源允许的情况下，可以适当增加容器的内存 limits 和 requests，以满足应用的内存需求，避免因内存不足导致应用性能下降或异常。例如，将 limits 调整为 8Gi，requests 调整为 7Gi。
升级 JVM 版本
- 当前使用的 Java 版本是 1.8.0_161，建议升级到更高版本的 JVM，如 Java 11 或 Java 17，这些版本在性能、稳定性和功能方面都有较大提升，同时也能更好地支持新的垃圾回收器和调优参数。
其他调优参数
- 增加线程堆栈大小 ：如果应用是多线程的，可以适当增加线程堆栈大小，避免因栈溢出等问题影响应用性能，如设置 -Xss512K。
- 优化类加载和 Metaspace ：根据 jstat -gcmetacapacity 的输出，Metaspace 使用情况尚可，但如果应用使用了很多类，可以适当调整 Metaspace 大小，如设置 -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=512M。

以下是调整后的 Dockerfile ENTRYPOINT 示例：

ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom", "-XX:+UseG1GC", "-XX:MaxGCPauseMillis=200", "-XX:InitialHeapOccupancyPercent=40", "-Xms5G", "-Xmx5G", "-XX:NewRatio=3", "-Xss512K", "-XX:MetaspaceSize=128M", "-XX:MaxMetaspaceSize=512M", "-jar", "/app.jar", "--spring.profiles.active=pro"]

需要注意的是，以上调优建议需要根据实际应用情况进行调整和测试，以找到最适合的参数组合。在调优过程中，要密切监控应用的性能指标和内存使用情况，以便及时做出进一步的优化决策。同时，升级 JVM 版本前，需要充分测试应用在新版本下的兼容性和性能表现，确保应用能够稳定运行。

详细解释各个参数作用，为什么这么设置？

以下是对各个 JVM 参数的详细解释：

`-Djava.security.egd=file:/dev/./urandom`

作用：设置 Java 安全随机数生成器的种子源为 /dev/./urandom。
原因：在某些 Linux 系统中，使用默认的随机数生成器可能会导致启动缓慢等问题。指定 /dev/./urandom 可以提高随机数生成的效率，从而加快 Java 应用的启动速度，尤其在需要大量随机数的场景（如加密操作）下效果明显。

`-XX:+UseG1GC`

作用：启用 G1 垃圾回收器。
原因：G1 垃圾回收器是一种服务器风格的垃圾回收器，它在垃圾收集时可以实现暂停时间的可预测性。它将堆内存划分为多个区域（Region），然后根据暂停时间目标（由 -XX:MaxGCPauseMillis 设置）来确定要收集的区域数量。与默认的 Parallel GC 相比，G1 GC 更适合处理大内存堆和需要较低停顿时间的应用场景，可以更好地平衡垃圾回收和应用吞吐量。

`-XX:MaxGCPauseMillis=200`

作用：设置最大垃圾回收停顿时间目标为 200 毫秒。
原因：这个参数是用来控制 G1 GC 的停顿时间的。通过设置这个目标，可以让 G1 GC 尽量在每次垃圾回收时将停顿时间控制在 200 毫秒以内，从而减少对应用运行的干扰，提高应用的响应性。当然，实际停顿时间可能无法完全保证在这个范围内，但 G1 GC 会尽力去接近这个目标。

`-XX:InitialHeapOccupancyPercent=40`

作用：设置初始堆内存占用比例为 40%，即当堆内存使用率达到 40% 时，G1 GC 会开始垃圾回收。
原因：这个参数影响 G1 GC 的垃圾回收触发时机。如果设置得过低，可能会导致垃圾回收过于频繁，影响应用性能；如果设置得过高，可能会导致堆内存不足，引发 Full GC 或者应用性能下降。设置为 40% 是一个相对合理的值，可以根据实际应用的内存使用模式进行适当调整。

`-Xms5G`

作用：设置 JVM 堆内存的初始大小为 5GB。
原因：根据主机内存使用率高（98%）和容器内存限制（limits 为 7Gi，requests 为 6Gi）的情况，将堆内存初始大小设置为 5GB 是一个相对合理的值。这样可以避免堆内存初始过小导致频繁的垃圾回收，同时也不会过度占用容器内存资源，避免主机内存过度使用。

`-Xmx5G`

作用：设置 JVM 堆内存的最大大小为 5GB。
原因：与 -Xms 一样，将堆内存最大大小设置为 5GB 是为了更好地控制 JVM 的内存使用，使其在容器内存限制和主机内存资源范围内合理运行。这样可以防止 JVM 堆内存无限增长，导致容器或主机内存不足的问题。

`-XX:NewRatio=3`

作用：设置新生代和老年代的比例为 1:3，即新生代占堆内存的 1/4，老年代占堆内存的 3/4。
原因：根据当前新生代 Eden 区使用率高达 89.46% 的情况，适当增加新生代大小可以减少 Eden 区溢出到老年代的频率，从而降低 Full GC 的发生次数。新生代是对象最初创建的地方，大多数对象在新生代中诞生并很快被回收，所以适当增大新生代可以更好地适应这种情况，提高垃圾回收效率。

`-Xss512K`

作用：设置每个线程的堆栈大小为 512KB。
原因：如果应用是多线程的，线程堆栈大小会影响线程的创建和运行。设置合适的线程堆栈大小可以避免因堆栈溢出等问题导致应用异常。默认的线程堆栈大小可能较大（如 1MB），适当减小可以节省内存，特别是在线程数量较多的情况下，能有效地减少内存占用。

`-XX:MetaspaceSize=128M`

作用：设置 Metaspace 的初始大小为 128MB。
原因：Metaspace 是用来存储类的元数据的内存区域。设置初始大小可以避免 Metaspace 过小导致频繁的扩展操作，提高类加载的效率。同时，128MB 的初始大小对于大多数应用来说是一个合理的起点，可以根据实际应用的类加载情况进行调整。

`-XX:MaxMetaspaceSize=512M`

作用：设置 Metaspace 的最大大小为 512MB。
原因：限制 Metaspace 的最大大小可以防止其无限制地增长，避免因类加载过多导致内存占用过多的问题。512MB 的最大值在大多数情况下可以满足应用的类加载需求，同时也能防止 Metaspace 过度占用内存资源，影响其他内存区域的使用。