Jenkins内置(master)节点CPU持续高占用致超时问题排查咨询

最高优先级修复：删掉生产环境不该存在的JVM参数 #

你当前JVM启动参数里混了两个开发调试用的参数，是CPU打满的核心诱因，先删了重启，90%概率直接恢复正常：

• 删掉远程调试参数组：-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=0。哪怕没有调试器连接，JDWP调试模式也会给所有方法调用插桩，带来持续的性能开销，新任务进队列时调度逻辑方法调用量暴涨，CPU直接被吃满。
• 删掉G1诊断参数组：-XX:+UnlockDiagnosticVMOptions -XX:G1SummarizeRSetStatsPeriod=1。这个参数是G1垃圾回收器开发阶段用的调试参数，配置为1意味着每次GC都全量计算、输出RSet统计信息，新任务进队列会触发更频繁的内存分配和GC，这部分无意义的统计计算直接就能把8核CPU占满。
  顺便把几个生产环境没必要开的GC日志参数也删掉，减少额外开销：-XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintReferenceGC -XX:+PrintAdaptiveSizePolicy。这些都是GC调优阶段临时开的详细日志项，长期开会产生大量字符串拼接、磁盘IO开销，积少成多也会拖慢性能。

次优先级验证：内存&GC状态检查 #

你用的c5.2xlarge是8核16G规格，-XX:MaxRAMPercentage=60.0配置下JVM堆大概能分到9.6G（如果容器没单独做内存限制的话），内存容量本身是够的，但要做两个检查：

• 看GC日志（路径是$JENKINS_HOME/gc-%t.log），如果Full GC频率超过10分钟1次、单次GC停顿超过1s，说明存在内存泄漏：先检查构建历史是不是没设保留上限、有没有装长期不更新的第三方插件、视图是不是配置了过于复杂的正则过滤规则，这三个是Jenkins最常见的内存泄漏诱因。
• 把-Dpermissive-script-security.enabled=no_security这个参数也删掉。这个参数会关闭Pipeline脚本沙箱，每次脚本执行都会触发全量解析和权限校验，不仅有安全风险，还会带来额外CPU开销，脚本权限走正常的内置审批流程就行。

仍未解决时的运行时栈抓法 #

如果改完上面的配置CPU还是高，直接抓线程栈定位具体耗CPU的逻辑：

1. 执行docker exec -it <你的Jenkins容器ID> sh进入容器内部
2. 执行top -H -p 1，找到Java进程下CPU占比最高的线程，记下它的线程ID（比如线程ID是245）
3. 把线程ID转成16进制：printf "%x\n" 245，比如得到结果f5
4. 执行jstack 1 > /tmp/jstack.log导出全量线程栈，在日志里搜刚才得到的16进制值，看栈顶对应的方法属于哪个组件：
   • 如果是Git/GitHub相关类：检查SCM轮询间隔是不是设得太短（比如小于1分钟），仓库数量多的话开组织级仓库缓存，不要每个任务单独轮询
   • 如果是JavaMelody相关类：把监控采集间隔从默认1分钟改成5分钟，关掉不需要的方法级监控、SQL监控项，监控本身也会耗资源
   • 如果是队列调度类插件（比如Build Blocker、Priority Sorter）：先把插件升级到适配2.319.x LTS的最新版本，检查队列匹配规则是不是写得太复杂，这类插件每次新任务入队都会遍历全量队列做规则匹配，规则复杂了很容易占满CPU
   • 如果是其他第三方插件类：先禁用对应插件看CPU是不是回落，很多没维护的第三方插件都有死循环、内存泄漏的bug，不用的插件直接卸载不要留着

你当前把内置节点执行器数量设为0的配置是正确的，不要改这个配置，永远不要在内置节点跑构建任务。

内容的提问来源于stack exchange，提问作者João Amaro