Jenkins 个别 job 页面打开超时的解决方法

Table of Contents

背景

最近公司移动端使用的的持续集成系统 Jenkins 打开某些 job 页面 报出 504 超时错误。

而 Jenkins 其他页面都是正常的,可以快速访问,为了临时解决这个超时问题,只是重启了 Jenkins 服务,重启后,该 job 页面可以正常访问。过了几天,又发现了另一个 job 页面打开也是 504 超时,而其他的 Jenkins 页面也都是正常的。

解决步骤

登上 Jenkins 所在的机器,查看了 Jenkins 的日志,并没有发现错误异常。

查看 Nginx 的日志,发现:upstream timed out (110: Connection timed out) while reading response header from upstream

修改 Jenkins 服务的 Nginx 配置,添加了 proxy_read_timeout 180s;proxy_send_timeout 180s; 设置了后端服务响应请求和传回数据的时间为 3 分钟。

重新加载 Nginx 配置:nginx -s reload

再次打开 504 的页面,原来请求时长一分钟后请求不到数据直接报错,这个时候并没有报错,而是一直等待请求响应,在将近两分钟的时候,页面成功访问。

虽然打开了原本 504 的页面,但并没有解决实质性问题。为了彻底解决这个问题,重新审视前后两个出现 504 错误的 job,发现构建的总次数都接近 2W+,猜测可能构建的次数较多导致的。但是,查看了其他的 job,也有总构建次数达到 2W+ 的,但打开页面并没有出现 504。

再次登上 Jenkins 所在的机器上,查看两个超时 job 的 builds 目录, 发现两个 job 的 builds 目录下都含有所有的历史构建的目录。然后我又查看了其他构建总次数在 2W+ 并且可以正常访问的 job 的 builds 目录,发现只包含几十个历史构建的目录。

因此,推测两个打不开的 job 不是因为构建总次数过多,而是保留了所有的构建历史,导致打开时加载非常缓慢,以至于出现超时。

解决方法是将超时的 job 配置项中勾选 『丢弃旧的构建』,可以选择『保持构建的天数』或者『保持构建的最大个数』,不再保留更早的构建历史记录,比如我选择的是『保持构建的最大个数』为 20 个,即只保留 20 个最近构建的记录。

配置好后,原本 504 的页面可以正常访问。

其他

为了防止其他潜在的 job 由于构建总次数过多且没有设置丢弃旧的构建导致以后打开超时,进入到 Jenkins 的 jobs 目录下,执行如下命令

for d in `ls`; do if [ -e $d/builds ]; then echo $d `ls $d/builds -lR | grep "^d" | wc -l`; fi; done

这条命令将遍历所有的 job 目录,在每个 job 目录中统计 builds 目录下的历史构建目录有少个,这样就可以发现有哪些 job 明显的构建总次数过多且没有设置丢弃旧的构建,将它们挨个配置『丢弃旧的构建』,排除潜在的超时风险。