Question

我的Jenkins版本是Jenkins 1.508。一些谷歌搜索似乎表明我需要在我的jenkins.xml中进行一些小改动（例如参见http://devophuman.blogspot.nl/2013/04/jenkins-is-going-wild.html），但是在我的情况下，xml的改变并没有多大帮助。今天我安装了监控插件，可以看到jenkins需要112,978毫秒来响应我的请求，我应该在哪里查找罪魁祸首？

Answer 1

我建议检查几件不同的东西。

jenkins进程是否固定在 100％CPU或更高？这可能表明，例如，有太多的构建被保留（Jenkins似乎有麻烦;我通常保持不超过 25个每个作业的构建来帮助防止性能这个问题）。我注意到Performance插件也会导致CPU使用率过高，特别是当它绘制图形时（Jenkins没有缓存也没有保存到磁盘，所以每个页面加载他们需要重新创建）。
Jenkins访问日志说什么？它是否会快速注册您的请求，但然后坐在那里似乎什么都不做？如果是这种情况且CPU未与jenkins进程挂钩，则可能是浏览器问题。

我发现即使在5分钟以上之后页面也没有加载，但是那里似乎没有基于jenkins的服务器上的负载，也没有任何严重的负载在其他地方的盒子上。我一直在使用Firefox来访问页面，当我在Chrome中尝试同一页面时，它已加载即刻。然后我可以回到Firefox并再次加载它。因此，浏览器在Jenkins方面的某个时间点出现了问题（不确定它是什么）。所以现在我通常使用Chrome来访问 Jenkins并且从那时起就没有真正注意到慢/非加载页面。

根据OP的评论进行编辑：

为了清理旧版本，我采用了两阶段流程：

导航到Jenkins安装的作业目录，然后导航到要清理的每个作业的版本目录。从那里简单地删除您不再需要的构建目录（使用您喜欢的任何shell工具 - 查找等）如果问题太多，那么在文件系统级别清除这些应该允许{{1}要加载的页面和视图。
如果清理然后允许您加载作业的页面，则可以单击Jenkins操作以更改配置并选择保留有限数量的构建的选项，将其设置为较低的值，例如25。

如果Configure进程没有固定在高CPU数量上，那么问题的构建数量似乎不太可能，但它可能值得一试。如果您认为以后可能需要更新构建信息，只需将它们移动到作业文件夹层次结构之外的位置，而不是删除它们，Jenkins也不会知道它们。您可以随时将其移回。

最好在Jenkins停止的情况下进行文件级移动，然后在清理完成后重新加载它。然后它将有更少的构建来迭代。

根据OP的后续评论进行编辑：

Re：第1点，这听起来肯定会出现安装问题（交叉链接的单独安装，或类似的东西）。

Re：第2点：这部分取决于Jenkins的安装方式。即它是在Tomcat上运行，还是在独立运行？

重新：第3点：这个真的听起来像你可能有交叉链接的安装。如果你停止了Jenkins，那么GUI真的应该不再有用了。

Re：第4点：11秒肯定是2分钟后的巨大进步。这肯定表明太多的保持构建是一个问题，但是在相对空闲的系统上加载页面真的应该很快，所以听起来可能还有一些其他问题，特别是各种各样的交叉安装。

是否有多个 jenkins 进程正在运行？ Tomcat 是否参与？

根据OP的后续评论进行编辑：

鉴于您对不回忆原始安装细节的意见，我认为最好只使用自包含（即非Tomcat）方法从头开始安装Jenkins，然后从旧安装中迁移数据正如我之前提到的，为了以防万一，首先将整个作业目录复制到别处。

这样您就可以确定安装细节并保存数据。

Answer 2

以我的经验，它与Windows文件系统有关，在处理带有许多子文件夹的文件夹时确实很糟糕。加载视图可能需要一分钟。

我们通过减少每个作业存储的默认版本，并按照khampson的建议删除旧版本，再次使Jenkins Views快速。

我希望在Linux上运行的Jenkins能够更好地处理大量构建

Answer 3

将Jenkins升级到版本1.568并清理作业目录后，当天第一次通话的典型响应时间降至约20秒。我认为“当天的第一个电话”在这里很重要，因为当我转到另一台机器时，GUI立即呈现在那里。这可能与公司代理，此处和那里的缓存机制或内部jenkins实现有关，但我可以忍受当前的情况。

Answer 4

我们已经实施了快速而肮脏的工作。只需在Jenkins中创建一个定期调用以下shell脚本的作业：

wget http://localhost:8080/view/All/ -O /dev/null

这为我们的用户减少了所有视图的加载时间（因为Jenkins必须自己动手）。

如评论中所述，wget仅加载作业视图。为了整合所有作业，我们使用以下curl脚本（基于Linux的主机）：

Jenkins 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

Jenkins 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]）

，您当然可以做同样的事情

Answer 5

对于原始海报来说，这可能不是问题，但我希望它可以帮助通过网络搜索到达此处的其他人。在我们的詹金斯案例中，大规模的UI减速原来是网络问题。我在办公室搬迁期间将服务器移到了一个临时位置，否则在Jenkins位置/ Jenkins URL中的设置将失败。暂时将其设置为主机名。本地使页面加载正常。

Answer 6

我在使用Windows服务运行的多个LTS Jenkins版本中遇到相同的问题。奇怪的是，以隐身模式启动Chrome，然后浏览到Jenkins URL，Jenkins的加载速度明显加快。用于多个用户的绘画大约需要1分钟，而在隐身模式下，则只需不到5秒。我不确定为什么缓存是这样的问题。清除缓存可以在短时间内解决该问题，但是它会在几个小时内重新开始，因此隐身模式是解决之道。

Jenkins GUI仅在等待2分钟后显示

6 个答案: