背景

最近公司移动端使用的的持续集成系统 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 明显的构建总次数过多且没有设置丢弃旧的构建，将它们挨个配置『丢弃旧的构建』，排除潜在的超时风险。