文章jvm~jvm配置与系统配置的关系分享给大家，欢迎收藏Java资料网，专注分享技术知识

一 生产环境问题描述

keycloak是运行在jboss上面，并且部署到了容器里，在k8s上面进行编排，现在遇到gc在某个时刻垃圾回收速度变慢，CPU接近100%，容器导致存活探针失败，容器最后重启

二 问题分析与解决方案

这是一个典型的 JVM GC 问题导致的容器重启场景。让我分析一下你的配置和可能的原因：

2.1 问题分析

根据你的 devops.yaml 配置：

              value: "-Xms1024M -Xmx1024M -XX:ConcGCThreads=13 -XX:ParallelGCThreads=13 -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -Djboss.bind.address.management=0.0.0.0"

          resources:
            limits:
              memory: 10Gi     # 限制的内存量
              cpu: 2       # 限制的 CPU 核心数
            requests:
              cpu: 100m
              memory: 500m

          livenessProbe: #存活检测
            failureThreshold: 2 #探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod会被标记为未就绪，默认为 3，最小值为 1
            initialDelaySeconds: 120 #容器启动后要等待多少秒后就探针开始工作，单位"秒"，默认是 0 秒，最小值是 0
            periodSeconds: 10 #执行探测的时间间隔（单位是秒），默认为 10s，单位"秒"，最小值是 1
            successThreshold: 1 #探针检测失败后认为成功的最小连接成功次数，默认为 1
            timeoutSeconds: 5 #探针执行检测请求后，等待响应的超时时间，默认为 1s，单位"秒"，最小值是 1
            httpGet:
              path: /auth
              scheme: HTTP
              port: 8080

---

🔴 2.2 发现的关键问题

1. GC 线程数配置过高

-XX:ConcGCThreads=13 -XX:ParallelGCThreads=13

问题：你配置了 13 个并发 GC 线程和 13 个并行 GC 线程，但 CPU 限制只有 2 核！

• ParallelGCThreads=13：并行 GC 阶段使用 13 个线程
• ConcGCThreads=13：并发标记阶段使用 13 个线程

当 13 个线程竞争 2 个 CPU 核心时，会导致：

• 严重的 CPU 上下文切换
• GC 线程互相等待 CPU 时间片
• GC 暂停时间变长
• CPU 使用率飙升到 100%

推荐配置：

-XX:ParallelGCThreads=2 -XX:ConcGCThreads=1

公式参考：

• ParallelGCThreads = CPU 核心数（或稍少）
• ConcGCThreads = max(1, ParallelGCThreads / 4)

---

2. 堆内存设置过小

-Xms1024M -Xmx1024M

问题：Keycloak 是一个比较重的应用，1GB 堆内存可能不够用，尤其是：

• 用户会话多时
• 存在大量认证请求时
• Infinispan 缓存占用内存

这会导致：

• 频繁触发 GC
• Full GC 增多
• GC 时间变长

推荐：容器内存限制是 10Gi，可以适当增加堆内存：

-Xms2048M -Xmx4096M

---

3. 存活探针配置过于严格

livenessProbe:
  failureThreshold: 2      # 只允许失败 2 次
  periodSeconds: 10        # 每 10 秒探测一次
  timeoutSeconds: 5        # 超时 5 秒

问题：当发生 Full GC 或长时间 GC 暂停时：

• GC STW（Stop The World）可能超过 5 秒
• 只需要 2 次失败（20 秒内）就会重启容器
• 这个配置对 Java 应用过于苛刻

推荐调整：

livenessProbe:
  failureThreshold: 3      # 允许 3 次失败
  periodSeconds: 15        # 每 15 秒探测
  timeoutSeconds: 10       # 超时 10 秒

---

4. 缺少关键的 G1GC 调优参数

当前配置缺少：

• 最大 GC 暂停时间目标
• G1 Region 大小
• 堆内存使用率阈值

---

三 优化JAVA_OPTS配置

问题：-XX:+PrintGCDetails 在 Java 9+ 已被弃用，应该使用统一的 -Xlog 语法。
优化建议的完整 JAVA_OPTS

非堆内存限制

-XX:MaxMetaspaceSize=512M
-XX:MaxDirectMemorySize=512M
-XX:ReservedCodeCacheSize=256M

并行与并发配置过于保守，可根据CPU核数来配置，如4核的CPU配置如下

• ParallelGCThreads 并行GC线程数（约为CPU核数的5/8）
• ConcGCThreads 并发GC线程数（约为ParallelGCThreads的1/4)

-XX:+UseG1GC
-XX:ParallelGCThreads=4
-XX:ConcGCThreads=1
-XX:MaxGCPauseMillis=200

完整的JAVA_OPTS配置

- name: JAVA_OPTS
  value: >-
    -Xms10240M
    -Xmx10240M
    -XX:+UseG1GC
    -XX:ParallelGCThreads=5
    -XX:ConcGCThreads=2
    -XX:MaxGCPauseMillis=200
    -XX:G1HeapRegionSize=16M
    -XX:InitiatingHeapOccupancyPercent=45
    -XX:MaxMetaspaceSize=512M
    -XX:MaxDirectMemorySize=512M
    -XX:ReservedCodeCacheSize=256M
    -XX:+HeapDumpOnOutOfMemoryError
    -XX:HeapDumpPath=/tmp/heapdump.hprof
    -Xlog:gc*:file=/tmp/gc.log:time,uptime,level,tags
    -Djboss.bind.address.management=0.0.0.0

文章来源:https://www.cnblogs.com/lori/p/19403589
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！