我的 Jenkins 版本是 Jenkins 1.508。一些谷歌搜索似乎表明我需要在我的 jenkins.xml 中进行一些小的更改（例如参见 http://devophuman.blogspot.nl/2013/04/jenkins-is-going-wild.html），但对我而言，xml 更改并没有太大帮助。今天安装了监控插件，可以看到jenkins响应我的请求需要112978毫秒，应该去哪里找罪魁祸首呢？
【问题讨论】：
标签： jenkins
我建议检查几个不同的东西。
jenkins 进程是否与 100% CPU 或更高挂钩？例如，这可能表明存在太多构建（Jenkins 似乎对此有问题；我通常保留不超过 每个作业 25 个构建，以帮助防止性能问题这）。我注意到Performance 插件也可能导致 CPU 使用率过高，尤其是在绘制图形时（Jenkins 不缓存也不保存到磁盘，因此每个页面加载都需要重新创建）。
Jenkins 访问日志说什么？它是否会快速注册您的请求，但随后似乎无所事事？如果是这种情况并且 CPU 没有与jenkins 进程挂钩，则可能是浏览器问题。
我发现页面在 5 分钟后仍未加载，但是
服务器上似乎没有基于jenkins的负载，也没有任何严重的负载
在其他地方的盒子上。我一直在使用Firefox 来访问
页面，当我在Chrome 中尝试相同的页面时，它加载了
即刻。然后我可以回到Firefox，它再次无法加载。
所以当时浏览器在Jenkins 方面出现了问题（不太确定是什么）。所以现在我一般使用Chrome来访问
Jenkins 并没有真正注意到页面加载缓慢/不加载。
根据 OP 的评论进行编辑：
为了清理旧版本，我采用了两个阶段的过程：
Jenkins 安装的jobs 目录，然后进入要清理的每个作业的builds 目录。从那里简单地删除您不再需要的构建目录（使用您喜欢的任何 shell 工具 - 查找等）如果构建过多是问题，那么在文件系统级别清理这些应该允许 Jenkins 页面和要加载的视图。Configure 操作更改配置并选择保留有限构建数量的选项，将其设置为较低的值，例如25 岁。如果jenkins 进程没有与高 CPU 数量挂钩，那么问题似乎不太可能是构建数量，但可能值得一试。如果您认为稍后可能需要返回构建信息，只需将它们移动到 jobs 文件夹层次结构之外的位置，而不是删除它们，Jenkins 不会知道它们。您以后可以随时将其移回。
最好在 Jenkins 停止的情况下进行文件级移动，然后在清理完成后重新加载它。这样它就可以迭代更少的构建。
根据 OP 的后续评论进行编辑：
回复：第 1 点，这听起来肯定是安装存在问题（交叉链接的单独安装，或类似的东西）。
回复：第 2 点：这部分取决于 Jenkins 的安装方式。即它是在 Tomcat 上运行，还是独立运行？
回复：第 3 点：这真的听起来您可能有交叉链接安装。如果你停止了 Jenkins，GUI 真的应该不再工作了。
Re：第 4 点：11 秒肯定比 2 分钟有很大改进。这绝对表明太多的保留构建是一个问题，但是页面确实应该非常快地加载到相对空闲的系统上，所以听起来可能还有其他一些问题，尤其是各种交叉链接安装。
是否有不止一个 jenkins 进程在运行？是否涉及Tomcat？
编辑以回应 OP 的后续评论：
鉴于您的 cmets 不记得原始安装的详细信息，我认为最好使用自包含（即非 Tomcat）方法从头开始安装 Jenkins，然后从旧安装迁移您的数据正如我之前提到的，为了以防万一，首先将整个作业目录复制到其他地方。
这样您就可以确定安装细节并保留数据。
【讨论】：
根据我的经验，它与 Windows 文件系统在处理具有大量子文件夹的文件夹方面非常糟糕有关。加载视图可能需要一分钟。
我们通过减少每个作业存储的默认构建并按照 khampson 的建议删除旧构建，再次加快了 Jenkins 视图的速度。
我希望在 Linux 上运行的 Jenkins 能够更好地处理大量构建
【讨论】：
这可能不是原始海报的问题，但我希望它可以帮助通过网络搜索登陆这里的其他人。在我们的 Jenkins 案例中，UI 的大幅下降原来是网络问题。我在办公室搬迁期间将服务器移动到了一个临时位置，Jenkins Location/Jenkins URL 中的设置会失败。将其临时设置为 hostname.local 使页面加载恢复正常。
【讨论】：
将 Jenkins 升级到 1.568 版并清理作业目录后，一天中第一次调用的典型响应时间缩短到大约 20 秒。我认为“当天的第一次通话”在这里很重要，因为当我然后转到另一台机器时，GUI 会立即呈现在那里。这可能与公司代理、各处的缓存机制或内部 jenkins 实现有关，但我可以接受目前的情况。
【讨论】：
我们已经实施了一项快速而肮脏的工作。只需在 Jenkins 中创建一个定期调用以下 shell 脚本的作业：
wget http://localhost:8080/view/All/ -O /dev/null
这为我们的用户减少了所有视图的加载时间（因为 Jenkins 必须自己承担）。
如评论中所述，wget 仅加载作业视图。为了交互所有作业，我们使用以下 curl 脚本（基于 Linux 的主机）：
詹金斯 1.x;
for x in ` curl 'http://localhost:8080/api/xml?tree=jobs\[url\]' | sed 's/<url>/\n/g' | sed 's/<\/url>//g' | sed 's/<job>//g'| sed 's/<job>//g' | sed 's/<\/job>//g' | grep http | sed 's/your.jenkins.host.domain/localhost:8080/' ` ; do curl "$x" -o /dev/null ;done
詹金斯 2.x;
for x in ` curl 'http://localhost:8080/api/xml?tree=jobs\[url\]' | sed 's/<url>/\n/g' | sed 's/<\/url.*//g' | grep http | sed 's/your.jenkins.host.domain/localhost:8080/' ` ; do curl "$x" -o /dev/null ;done
您当然可以对同一件事进行查看 (http://localhost:8080/api/xml?tree=views[url])
【讨论】：
多个 LTS Jenkins 版本作为 Windows 服务运行时，我遇到了同样的问题。奇怪的是，在隐身模式下启动 Chrome，然后浏览到 Jenkins URL，Jenkins 的加载速度明显更快。为多个用户绘制大约需要 1 分钟，但在隐身模式下需要不到 5 秒。我不确定为什么缓存是这样的问题。清除缓存可以在短时间内解决问题，但它会在几个小时内重新开始，因此隐身模式是可行的方法。
【讨论】：