当前位置: 首页 > news >正文

jvm~jvm配置与系统配置的关系

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
http://www.gsyq.cn/news/1614106.html

相关文章:

  • MEC152x嵌入式控制器BIOS移植与eSPI接口配置实战指南
  • 【分享】阿贝云免费云服务器使用心得
  • Codex已被GPT-4o代码能力全面替代?权威Benchmark对比报告(含HumanEval/MBPP/DS-1000三维度压测数据)
  • MC9S12XDP512 Flash编程与安全机制实战详解
  • I2C总线协议深度解析与MCF5251实战编程指南
  • rat项目架构解析:理解Rust重构cat工具的设计哲学与实现原理
  • 手写笔记终极指南:Xournal++跨平台解决方案完全手册
  • 云顶之弈终极攻略:如何用TFT Overlay免费工具轻松提升段位
  • ASD433A评估板硬件解析:PowerPC MCU电源、时钟与启动配置实战
  • 汽车级MCU评估板硬件设计解析:电源、时钟与调试接口配置实战
  • 如何在Blender中无缝导入Rhino 3DM文件:终极解决方案指南
  • WarcraftHelper:用模块化插件架构让经典魔兽争霸3在现代系统上重生
  • DVWA靶场实战:从零搭建到SQL注入与XSS漏洞攻防详解
  • 不用安装专用客户端:用Copyparty给NAS增加网页上传与文件分享
  • Python网站离线下载器:一键保存完整网站的终极解决方案
  • MPC5643L/SPC56EL评估板硬件设计详解:电源、时钟与启动配置实战
  • VS Code十六进制编辑器终极指南:二进制文件编辑从未如此简单
  • USB设备控制器驱动开发:队列头与传输描述符的实战解析
  • IPXWrapper终极指南:Windows 10/11经典游戏联机完整解决方案
  • 【OpenAI企业版成本黑洞预警】:3类隐性支出正在吞噬ROI!附自动化用量监控脚本(Python+Prometheus开源可复用)
  • 模板驱动型文档自动化:结构化内容与零代码生成实战
  • ASD433A评估板硬件配置与调试指南:PowerPC汽车MCU开发实战
  • MPC7410 L2缓存配置、测试与总线交互实战指南
  • Claude layer-zero:长上下文指令零遗忘的动态语义锚定技术
  • 零成本 AI 文案工具|Streamlit 三模式叙事生成完整源码分享
  • MPC5643L评估板硬件设计解析:电源、时钟与启动配置实战
  • TPA3128D2与PIC18LF45K40打造高性价比D类音频放大器
  • 【独家信源】OpenAI新成立“AI治理特别委员会”:5条即将落地的合规红线,9月30日前必须完成自查
  • 抖音批量下载器终极指南:3分钟学会高效下载无水印视频和音乐
  • PowerPC评估板硬件设计解析:从电源管理到调试接口实战