记一次 nginx 502 问题排查解决思路和过程！

记一次 nginx 502 问题排查！

总结：nginx502：Tomcat调优之acceptCount

问题背景：UI 页面点击会偶尔返回 error，检查调用日志，发现 nginx 报 502 报错，因此本文即排查 502 报错原因。

如下红框可知，访问本机个备机的服务 502 了，用时 3 秒左右（可见并不是超时）。

先给出原因：是因为 tomcat8 默认的 acceptCount 是 100，请求量大的时候，会将一些来不及处理的请求塞到 acceptCount，当 acceptCount 塞满的时候，请求会被丢弃，即我们上面说的 nginx 报的 502 错误。

解决方案：将 acceptCount 调大，目前线上调整到了 10000，经 16 小时的观察，没有再报 502 错误，问题得以解决。

排查过程：

怀疑一：首先发现 DB 的压力突增，见图，但是 DBA 帮排查后，这个时间点并没有慢查询，因此怀疑是否是服务器的问题。

怀疑二：是不是有一台服务有问题。

但是经排查 nginx 日志，两台服务都有 502 出现。因此这个情况排除

怀疑三：tomcat 的本身的问题。

由于 nginx 出现 502 的时候，时间有的只有3秒或者更小，因此也不是访问 tomcat 超时的，所以最大的可能就是 tomcat 丢弃了请求，经确认确实是丢弃了。

怎么证明这个推断呢？

首先：看请求是否进入 tomcat 了，好在我们配置了 tomcat 的访问日志记录：配置如下：

日志：检查 502 请求的时间，在 tomcat 里面没有记录日志，可见并没有进入 tomcat，从而论证了上面的观点：502 是因为请求被丢弃了。

那么为什么会丢弃呢？

看了一些 tomcat 的默认配置，几个重要的配置。参考：Apache Tomcat 8 Configuration Reference (8.5.78) - The HTTP Connectorhttps://tomcat.apache.org/tomcat-8.5-doc/config/http.html。

看到一个很重要的参数 acceptCount。acceptCount 是100，第一感官，太小了，超过这个队列就被丢弃了。

acceptCount 解释：当 maxConnections 超过 10000 万（tomcat 默认值是10000）的时候，会将多余的连接放到 acceptCount 中，即默认的 tomcat 可以支持的最大连接数是 10000 + 100 = 10100；

当超过 10100 的时候，请求就会被丢弃，即 nginx 的 502 日志，解决方法：将acceptCount调整成 10000。502问题得以解决。

注：

maxConnections 与 acceptCount 的关系。