我的Jenkins版本是Jenkins 1.508.一些谷歌搜索似乎表明我需要在我的jenkins.xml中进行一些小改动(例如参见http://devophuman.blogspot.nl/2013/04/jenkins-is-going-wild.html),但是xml更改了在我的情况下没有多大帮助.今天我安装了监控插件,可以看到jenkins需要112,978毫秒来响应我的请求,我应该在哪里查找罪魁祸首？
我建议检查一些不同的东西.
该jenkins流程是否为100%CPU或更高？这可能表明,例如,有太多的构建被保留(Jenkins似乎有这个问题;我通常每个作业保留不超过25个构建,以帮助防止性能问题).我注意到Performance插件也会导致CPU使用率过高,尤其是在绘制图形时(Jenkins不会缓存也不会保存到磁盘,因此需要重新创建每个页面加载).
什么是Jenkins访问日志说？它是否会快速注册您的请求,但然后坐在那里似乎无所事事？如果是这种情况并且CPU没有挂在jenkins进程上,则可能是浏览器问题.
我发现即使在5分钟以上之后页面也没有加载,但是jenkins服务器上似乎没有任何基于负载的负载,也没有任何其他方面的负载.我一直在使用Firefox访问页面,当我尝试同一页面时Chrome,它立即加载.然后我可以回去Firefox再次无法加载.所以在浏览器的那个时间点出现了问题Jenkins(不确定它是什么).所以现在我通常Chrome用来访问
Jenkins并且没有真正注意到缓慢/非加载页面.
编辑以回应OP的评论:
为了清理旧版本,我采用了两个阶段的过程:
Jenkins然后导航到要清理的每个作业的builds目录中.从那里简单地删除您不再需要的构建目录(使用您喜欢的任何shell工具 - 查找等)如果问题太多,那么在文件系统级别清理这些构建应该允许Jenkins页面和视图加载.Configure操作以更改配置并选择保留有限数量的构建的选项,将其设置为较低的值,例如25.如果这个jenkins过程没有挂在高CPU数量上,那么问题的构建数量似乎不太可能,但它可能值得一试.如果您认为以后可能需要更新构建信息,只需将它们移动到作业文件夹层次结构之外的位置而不是删除它们,Jenkins就不会知道它们.您可以随时将其移回.
最好在Jenkins停止的情况下进行文件级移动,然后在清理完成后重新加载它.然后它将有更少的构建来迭代.
编辑以回应OP的后续评论:
回复:第1点,这听起来好像安装可能存在问题(交叉链接单独安装,或类似的东西).
回复:第2点:这部分取决于Jenkins的安装方式.即它是在Tomcat上运行,还是与独立运行？
回复:3点:这真的听起来像你可能有交联的安装.如果你停止了Jenkins,GUI真的应该不再有用了.
回复:第4点:11秒肯定是2分钟后的巨大进步.这肯定表明太多的保持构建是一个问题,但页面真的应该是相当空闲的系统加载,所以听起来可能还有一些其他问题,特别是交叉安装排序.
是否有不止一个jenkins进程在运行？是Tomcat的参与？
编辑以回应OP的后续评论:
鉴于您对不回忆原始安装细节的意见,我认为最好只使用自包含(即非Tomcat)方法从头开始安装Jenkins,然后按照我提到的那样从旧安装迁移数据以前,为了以防万一,首先将整个作业目录复制到别处.
这样您就可以确定安装细节并保持数据.