今天上午十点团队消息群连着弹出好几条反馈“Jenkins页面又卡了”“登录之后一直在转圈”。一开始我以为是某个构建任务把资源占满了跑到服务器上一看才发现真正的问题藏在页面本身——前端访问卡顿持续了将近两周而根源居然是一个主题插件故障。这次排障从浏览器瀑布图一路追到JVM参数从主题插件的异常请求一直查到磁盘空间和并发配置最后才做完整体的性能调优。如果你正在维护Jenkins或者遇到过“页面慢但不知道从哪查起”的情况这篇记录应该能帮你少走不少弯路。1. 症状观察先把“卡顿”拆成可量化的指标卡顿是一个很模糊的词每个人说“卡”的时候指的可能完全不是一回事。有人是浏览器标签页一直转圈有人是登录之后点了菜单没反应还有人连登录页都刷不出来。如果不先把症状量化后面所有的排查都会变成瞎猜。1.1 浏览器开发者工具把“感觉卡”变成“数据卡”我让反馈问题的同事先录了一段现象然后自己在同一台电脑上用Chrome开发者工具复现了一次完整流程。关键看两个面板Network面板刷新页面看所有请求的耗时状态。重点留意哪些请求处于pending很久才结束哪些请求blocked阶段异常长。Performance面板录制一段完整操作看长任务Long Task集中在哪个阶段是脚本执行还是样式重排。这里有个基本判断逻辑它决定了排查方向DOMContentLoaded事件很久才触发说明HTML生成或首页后端渲染环节有问题。Load事件很晚才触发说明CSS、JS、图片这些静态资源加载慢或者存在阻塞渲染的资源。Performance面板里的长任务集中在一段脚本执行上那问题多半是前端脚本逻辑太重。我这次录制的结果是DOMContentLoaded勉强能接受但Load事件被拖到了10秒以上而且瀑布图里有一个请求卡了很久。直觉告诉我可能有某个脚本在页面加载过程中“堵住”了后续所有资源的渲染。1.2 登录前卡还是登录后卡决定不同的排查方向排查前我还习惯性问了一句是登录页就卡还是登录之后才卡这两个看似都是“卡顿”但排查路径完全不同登录前卡优先怀疑反向代理、静态资源服务器、认证服务和基础网络链路。登录后卡优先怀疑Jenkins系统首页相关的插件、后台任务、大数据量的接口响应、以及服务端的GC问题。我们的反馈集中在“登录之后卡”登录页本身打开速度正常。这说明认证链路、代理和静态资源都没大问题问题出在登录后的首页和菜单渲染阶段。这条线索很重要直接把排查范围从“整个平台”缩小到了“登录后要加载的模块”。1.3 服务端基础指标也不能漏在动浏览器之前我还并行看了一眼服务端的基础状态top看CPU和内存Java进程CPU占用在30%左右浮动内存还没到瓶颈。df -h看磁盘发现/var/lib/jenkins所在分区使用率已经超过80%剩余空间不多了。free -h看系统内存总量4G已经用了大半。CPU只有30%却让人感觉卡死说明瓶颈大概率不在纯CPU计算上。磁盘使用率偏高可能对写入操作有影响但也解释不了页面渲染卡那么久。我把这些问题先记录下来继续追前端证据。到这一步我习惯给响应时间建一个简单的参考基准方便后续比较页面加载耗时体验等级小于2秒基本无感可接受2~4秒能察觉到延迟4~8秒明显卡顿用户开始投诉8秒以上不可用状态这次的情况明显在8秒以上属于不可用级别。2. 排查真凶一个主题插件的请求为什么能让页面白屏有了前面的量化数据接下来就是顺着Network面板里的瀑布图把那个“异常请求”揪出来。2.1 瀑布图里的异常请求在Network面板里按耗时排序排在第一个的是一个XHR请求耗时将近9秒。时间几乎全花在Waiting (TTFB)等待服务器首字节阶段。TTFB一直挂着说明这不是浏览器端渲染慢而是这个请求本身迟迟拿不到响应。我点开请求详情看了一眼发起方发现它不是Jenkins核心页面发出的请求而是来自后来引入的一套主题插件。这套插件会在全局页面里注入一段脚本页面加载时脚本先去请求一个外部地址拿到数据后再动态拼接侧边栏和顶栏菜单。这里需要解释一下浏览器渲染阻塞的原理。浏览器拿到HTML后是边解析边构建DOM树的。当解析到普通script标签时浏览器会停下所有工作先去执行脚本。此时如果脚本里还发起了一个同步网络请求整个页面的后续解析都会被这个请求卡住。等请求结束浏览器才能继续渲染后面的节点。主题插件的坑就在这里它为了统一视觉风格会把自定义脚本以同步方式注入每个页面一旦脚本依赖的外部资源不通用户看到的就是标签页一直转圈、点哪里都没反应。2.2 主题插件典型的几种拖慢页面方式这次遇到的只是其中一种我在不同环境里还见过另外几种写出来供参考外部资源引用导致网络阻塞主题的CSS或JS里直接引用了远程字体库、远程图标库。用户侧访问这些地址不畅时请求一直挂着页面就一直等待。内嵌脚本过重主题插件在页面加载阶段执行了大量DOM遍历、字符串拼接、HTML注入操作执行几百毫秒甚至几秒期间页面完全无响应。主题配置不缓存插件每次刷新都重新读取配置、重新加载样式没有做本地缓存。配置读取加上样式重新计算放大了页面的渲染成本。与其他插件冲突主题插件注入的全局样式和别的插件样式选择器互相覆盖触发大量重排和重绘肉眼看起来就是页面帧率低、滚动都卡。主题插件的特殊性在于它注入的代码出现在每个页面而且它通常不直接参与构建任务团队平时关注度低。出了问题很容易被误判成“Jenkins平台本身就很慢”然后大家一起去加内存、换机器问题却依然在。2.3 对比实验坐实“真凶”为了确认不是巧合我做了一个最简单的AB对照实验。进入系统管理Manage Jenkins→ 插件管理 → 已安装插件找到那套主题插件直接点击禁用。禁用后刷新页面页面加载时间从9秒左右降到了3秒多。重新启用插件刷新一次卡顿立刻回来。对比结果非常干净基本实锤就是它。随后我又去翻Jenkins系统日志找到了指向外部地址的连接超时记录进一步印证插件脚本引用的外部资源不可达导致同步脚本一直阻塞页面渲染。3. 修复主题插件故障的完整操作链确认真凶之后剩下的问题就变成怎么修以及怎么防止它再犯。3.1 应急处理禁用插件让服务先恢复第一步当然是先禁用插件让团队恢复正常使用。操作路径系统管理Manage Jenkins→ 插件管理 → 已安装插件在列表里找到目标主题插件勾选后点击禁用。部分插件禁用后可以立即生效另一些需要重启Jenkins才能完全卸载掉钩子。如果遇到后者可以通过“系统管理 → 重启Jenkins”来做一次受控重启。这里有个经验重启前一定要跟团队同步时间最好选在构建任务少的低峰期否则正在跑的流水线全部中断后果比卡顿还麻烦。重启完成后我立刻在无痕窗口里再开一次Jenkins页面确认登录和首页都恢复正常然后再通知团队“可以继续用了”。3.2 根治清理插件配置移除外部依赖禁用只是止血插件里的外部依赖还在下次启用照样卡。我找到JENKINS_HOME下的插件配置目录定位到主题插件的XML配置文件里面明确写着外部资源地址。我把配置文件做了备份然后直接删除掉那部分外部资源引用让主题退回到最基础的本地样式。如果你的场景里主题只是用来换个颜色和Logo这一步基本就够用了。然后还要清理浏览器侧的缓存。主题插件经常会把渲染结果或者配置信息存在localStorage/sessionStorage里如果不清理即使服务端已经修好浏览器端还可能用旧缓存继续渲染。操作方式是在Chrome开发者工具的Application面板里清掉对应站点的本地存储再强制刷新一次。重新配置主题时我强烈建议把CSS、JS、字体这类资源全部本地化也就是把它们下载下来放到Jenkins能访问到的内网静态资源服务里不要继续引用外网URL。3.3 防御防止同类问题再次拖垮页面性能问题修完只是开始怎么防复发才是重点。经过这次排障我给自己定了几条规则引入或升级任何插件之前先在测试环境里装一遍跑一次页面加载回归确认没有外部依赖和同步阻塞脚本再上生产。如果确实必须引用外部脚本给script标签加上defer或async属性。区别在于defer会等HTML解析完再执行脚本async允许脚本下载和执行不阻塞页面解析至少不会让整个页面一直白屏等着一个外部请求。定期盘一下“已安装插件”列表凡是全局注入脚本的插件必须严格审核它的加载逻辑。不用的插件及时卸载别留着一堆没人维护的钩子。建一个简单的基线回归流程每次Jenkins大版本升级后用固定浏览器清缓存刷新首页记录Load事件时间超过阈值就报警。4. 顺藤摸瓜JVM参数、磁盘空间与并发模型一起调主题插件修好了页面确实快了很多但还没到我满意的程度。3秒多的加载时间勉强能接受可首页接口的TTFB依然偶发跳高。加上前面记录的磁盘使用率偏高我决定继续往下查把Jenkins服务端本身的状态也调一遍。4.1 先看JVM堆内存、GC日志和启动参数Jenkins是Java应用跑在应用容器里JVM参数直接决定它的内存表现。我先看了启动方式。我这台机器用的是systemd托管服务执行systemctl status jenkins可以找到启动文件位置再通过systemctl cat jenkins查看启动参数里的-Xms和-Xmx。检查结果很典型堆内存设置偏小而且-Xms和-Xmx不一致。-Xms是JVM启动时的初始堆大小-Xmx是最大堆大小。两者不一致时JVM会在使用过程中反复扩容和收缩这个调整过程本身就有开销。更重要的是堆太小会导致对象分配困难触发频繁的GC。如何理解GC对页面卡顿的影响JVM进行Full GC时会触发“Stop The World”暂停所有应用线程都会停止工作。Full GC期间Jenkins的页面请求、构建调度、插件后台线程全部跟着暂停。如果Full GC每几分钟就来一次用户体感就是“页面时不时卡一下”叠加主题插件的脚本阻塞体验直接变成“长期卡死”。我这次的机器物理内存4G需要兼顾构建任务进程的内存占用最终把堆设定为2G并让-Xms和-Xmx相等。为什么不贪心设成3G或更高因为这台机器还要跑多个Maven和Node构建进程操作系统本身也要预留内存堆设得过大反而可能导致构建任务频繁被系统杀掉或者触发更严重的swap。具体做法是在systemd单元的启动环境变量里覆盖JAVA_OPTSJAVA_OPTS-Xms2g -Xmx2g -verbose:gc -Xlog:gc:/var/log/jenkins/gc.log注意-Xlog:gc:文件路径是JDK11以后的语法如果你还在用JDK8要写成-Xloggc:/路径/gc.log -verbose:gc。改完参数后执行systemctl daemon-reload和systemctl restart jenkins。重启后再观察GC日志Full GC的频率明显下降单次GC后的停顿时间也大幅缩短。GC日志这个文件平时没人看但排查卡顿问题时它是定位“服务端周期性停顿”最直接的工具。4.2 给Jenkins做一次“大扫除”磁盘、构建历史、工作空间JVM调完之后还要处理磁盘压力。磁盘使用率超过80%对频繁读写的Jenkins主目录影响很大尤其Indexing扫描和日志写入会变慢。我先执行df -h确认各个挂载点的使用率然后按顺序清理了三类内容第一类是构建历史。旧Job的构建记录、产物、日志占了大量空间。我通过“系统管理 → 脚本命令行Script Console”执行了一段Groovy脚本批量删除超过30天的构建记录。def daysToKeep 30 Jenkins.instance.getAllItems(Job.class).each { job - job.getBuilds().findAll { build - (System.currentTimeMillis() - build.getTimeInMillis()) daysToKeep * 24 * 60 * 60 * 1000L }.each { build - build.delete() } }这个脚本执行前最好先备份Jenkins主目录或者在测试实例上验证一次。虽然我没遇到问题但大量删除构建记录对某些插件的统计报表会有影响。第二类是工作空间目录。/var/lib/jenkins/workspace下堆积了很多长期不用的目录每个都有几百MB甚至几GB。我把确定不用的直接删除并在还在活跃的Job配置里开启了“丢弃旧的构建”保留最近N次成功和失败记录避免再次堆积。第三类是日志和临时文件。$JENKINS_HOME/logs目录下有不小体积的旧日志/tmp下面也有Jenkins产生的临时文件。清理之后磁盘使用率从80%降到了50%以下。4.3 并发模型executor数量并不是越多越好清理完磁盘我又看了一眼并发配置。这是很多Jenkins管理员容易踩坑的地方。默认情况下master节点配置的executor数量如果偏高比如8个、10个每个构建任务都会争抢CPU和内存。master节点本身还要承担页面请求响应和插件调度构建任务一多页面交互自然变卡。executor的数量可以理解为Jenkins同时能跑的构建任务数。并不是数量越大吞吐越高超过CPU核心数之后任务之间互相抢时间片整体效率反而下降。我的做法是把master节点的executor数调整为CPU核心数减一比如4核机器上配置为2或3保留一个核心给页面响应和系统调度。如果团队有条件更好的方案是把构建调度到专门的agent节点master只做调度和UI展示。另外团队经常手动点多次“立即构建”的话可以适当配置“安静期”避免短时间触发大量重复构建把任务队列打爆。这一轮调优做完页面加载又稳了一截。这个时候再测数据和刚修完插件时已经有了明显变化。5. 实测数据复盘页面加载时间从8秒级降到2秒级调优有没有效果不能靠“感觉变快了”要用一组相对固定的方法测出可复现的数据。5.1 测法浏览器多次刷新 curl命令行验证我给这次验证定了一个最简单的流程避免测出来的数据被偶然因素干扰用无痕窗口打开Jenkins登录页排除浏览器插件和缓存干扰。每次完整刷新都等Network面板里的请求全部结束才关闭页面。连续测5轮取中间值而不是取最好的一次或第一次的结果——第一次请求往往会触发服务端预热和资源缓存不代表常态。除了浏览器我还会用curl从命令行侧验证HTTP接口的响应时间curl -o /dev/null -s -w TTFB: %{time_starttransfer}s\n总耗时: %{time_total}s\n http://Jenkins服务地址/login这里看两个指标time_starttransfer是“首字节时间”代表服务端处理和返回第一个字节的速度time_total是完整请求耗时。命令行测法和浏览器测法互相印证比单独看浏览器数据更可靠。5.2 修复前、修复后、调优后的对比我整理了一下这次排障不同阶段的实测数据指标修复前禁用主题插件后完成JVM/磁盘/并发调优后首页Load事件8~10秒3~4秒2秒左右登录后首页接口TTFB900ms级180ms级120ms级Full GC频率每5~10分钟一次仍有偶发每小时0~1次磁盘使用率80%以上80%以上50%以下CPU空闲率低时有尖刺明显改善整体平稳这些数据只是在当前环境下观察到的结果不同规模的Jenkins实例会有自己的基准但趋势基本是一致的先解除前端阻塞再解决服务端资源问题页面慢的问题才会彻底改观。如果只修了插件不管服务端后面GC或磁盘压力迟早还会把体验拖回去。5.3 一周稳定性观察和我养成的排障习惯调优结束后的那一周我没有再收到“Jenkins慢”的反馈。GC日志保持稳定构建发布流程也正常。这次之后我养成了一个习惯只要再有人报“Jenkins慢”我一定先问一句“是登录前慢还是登录后慢”然后打开瀑布图看那个卡住的请求到底是谁发起的。很多性能问题的答案往往就藏在平时最不关心的插件的某个外部请求里。如果你也打算给自己维护的Jenkins做一次体检我的建议很直接从浏览器瀑布图开始顺着异常请求往下追然后把服务端的JVM、磁盘、并发配置挨个过一遍。组合拳打下来大部分卡顿都比想象中好解决。