仅在等待2分钟后才会显示Jenkins GUI [英] Jenkins GUI only shown after waiting for 2 minutes

问题描述

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

My Jenkins version is Jenkins 1.508. Some googling around seemed to indicate that I needed a small change in my jenkins.xml (see for instance http://devophuman.blogspot.nl/2013/04/jenkins-is-going-wild.html), but that xml change did not help a lot in my case. Today I installed the monitoring plugin, and can see that jenkins needed 112,978 ms to respond to my request, where should I look for the culprit?

推荐答案

我建议您检查几件事.

1. jenkins进程是否固定在 100％CPU或更高上?例如，这可能表明存在过多的构建(Jenkins似乎有问题；我通常保留每个工作不超过 25个构建，以防止出现性能问题.这个).我注意到Performance插件也可能导致大量CPU使用，尤其是在绘制图形时(Jenkins既不缓存也不保存到磁盘，因此每个页面加载都需要重新创建).

1. Is the jenkins process pegged at 100% CPU or higher? This could indicate that there are, for example, too many builds being kept around (Jenkins seems to have trouble with this; I usually keep no more than 25 builds per job to help prevent performance issues from this). I've noticed the Performance plugin can also lead to intense CPU usage, especially when it is drawing the graphs (which Jenkins does not cache nor save to disk, so each page load they need to be recreated).

Jenkins访问日志说什么?它会快速注册您的请求，然后坐在那里似乎什么也没做吗?如果是这种情况，并且CPU没有挂在jenkins进程上，则可能是浏览器问题.

What does the Jenkins access log say? Does it quickly register your request but then sit there seemingly doing nothing? If this is the case and the CPU isn't pegged on the jenkins process, it may be a browser issue.

我发现即使超过5分钟也没有加载页面，但是 服务器上似乎没有基于jenkins的负载，也没有任何严重的负载 在其他地方的盒子上.我一直在使用Firefox来访问 页，当我尝试在Chrome中的同一页时，它已加载 即刻.然后，我可以返回到Firefox，它将再次无法加载. 因此，在那个时候，浏览器关于Jenkins出了点问题(不确定到底是什么).所以现在我通常使用Chrome来访问 Jenkins，此后并没有真正注意到缓慢/未加载的页面.

I found that pages weren't loading even after 5+ minutes, but there was seemingly no jenkins-based load on the server, nor any serious load on the box elsewhere. I had been using Firefox to access the pages, and when I tried the same page in Chrome, it loaded instantly. I could then go back to Firefox and it again would not load. So there was something wrong at that point in time with the browser with respect to Jenkins (not sure quite what it was). So now I generally use Chrome to access Jenkins and haven't really noticed slow/non-loading pages since.

根据OP的评论进行

为了清理旧版本，我采用了两个阶段的过程:

To clean up old builds, I employ a two-phase process:

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

1. Navigate to the jobs directory of your Jenkins install and then into the builds directories of each job you want to clean up. From there simply delete the directories of the builds you no longer want (using whatever shell tools you prefer -- find, etc.) If too many builds is the issue, cleaning these up at the file system level should then allow Jenkins pages and views to load.
2. If the cleanup then allows you to load the pages for the jobs, you can then click the Configure action to change the config and select the option to keep a limited number of builds, setting it to a lower value, such as 25.

如果jenkins进程不是以较高的CPU数量固定的，则似乎不太可能是问题的生成数量，但是可能值得尝试.如果您认为以后可能需要构建信息，只需将其移动到 jobs 文件夹层次结构之外的位置，而不是删除它们，Jenkins不会知道它们.您以后随时可以将其移回.

If the jenkins process isn't pegged at a high CPU number, it seems somewhat unlikely that it's the number of builds that are the issue, but it's probably worth a try. If you think you may want the build info back later, simply move them to a location outside the jobs folder hierarchy instead of deleting them and Jenkins won't know about them. You can always move it back later.

最好在Jenkins停止的情况下进行文件级移动，然后在清理完成后重新加载它.这样一来，要迭代的构建就会少得多.

It's probably best to do the file-level moving with Jenkins stopped, and then reload it once the cleanup is done. It will then have far fewer builds to iterate over.

根据OP的后续评论进行

回复:要点1 ，这听起来确实像是安装有问题(交叉链接的单独安装，或类似的东西).

Re: point 1, that definitely sounds like there might be an issue with the installation (cross-linked separate installs, or something like that).

回复:要点2 :这部分取决于Jenkins的安装方式.即它是在Tomcat上运行还是独立运行?

Re: point 2: That will depend in part on how Jenkins was installed. i.e. is it running on Tomcat, or with standalone?

回复:要点3 :听起来确实听起来像您可能具有交叉链接的安装.如果您停止了Jenkins，则GUI确实将不再起作用.

Re: point 3: This really sounds like you might have cross-linked installs. If you stopped Jenkins, the GUI really should no longer work.

回复:要点4 :11秒肯定是2分钟内的巨大改进.这绝对表明存在太多的构建问题，但这些页面确实应该非常活泼，以便在相对空闲的系统上加载，因此听起来还可能存在其他一些问题，尤其是各种交叉链接的安装.

Re: point 4: 11 seconds is certainly a huge improvement over 2 minutes. That definitely suggests that too many kept-builds was one problem, but the pages really should be pretty snappy to load on a relatively idle system, so it sounds like there may potentially be some other issues as well, particularly a cross-linked install of sorts.

是否正在运行一个以上的 jenkins 进程?是否涉及 Tomcat ?

Is there ever more than one jenkins process running? Is Tomcat involved?

根据OP的后续评论进行

鉴于您对不记得原始安装细节的评论，我认为最好是使用自包含(即非Tomcat)方法从头开始安装Jenkins，然后从旧安装中迁移数据正如我之前提到的，为防万一，首先将整个作业目录复制到其他位置.

Given your comments about not recalling the details of the original installation, I think it may be best to simply install Jenkins from scratch using the self-contained (i.e. non-Tomcat) method, and then migrate your data from the old install as I mentioned previously, copying the whole jobs directory elsewhere first just in case.

这样，您可以确定安装的详细信息并保留数据.

This way you can be sure of the installation details and get to keep the data.

这篇关于仅在等待2分钟后才会显示Jenkins GUI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！