9

记一次'nginx 499'排查经历

 2 years ago
source link: http://pein0119.github.io/2015/11/06/%E8%AE%B0%E4%B8%80%E6%AC%A1-nginx-499-%E6%8E%92%E6%9F%A5%E7%BB%8F%E5%8E%86/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

记一次'nginx 499'排查经历

昨天商家客服报了一个问题，有商家返回订单无法下载。我测试了一下，当下载时间超过10秒时，连接被强行断开，并在页面抛出504。
查看nginx日志，发现对应的请求返回的错误码为”499”。

“499”是nginx自定义错误码，意思是“客户端主动关闭连接”，就是PHP脚本执行的时间太长了，调用方关闭了连接。

解决过程：

1. 先确认是否是代码问题

报499的一个可能原因就是，有人调小了curl请求的超时时间，curl超时之后调用方主动关闭了连接。

  • 我先是查看了所有与该业务相关的代码的”svn log”,确定最近一段时间没有对相关代码修改。
  • 然后我去预上线环境测试了一下，尝试多次后，都没有出现该问题，那就应该不是代码的问题。

结论：代码问题被排除，有很大可能是线上环境问题。

2. 确认是否是环境问题

还是从日志着手

  • 取出了所有报“499”的php机器IP，不幸的是，所有机器都出现了这种问题，而且都是10s就断开连接。
  • 取出了所有报错的nginx机器的IP,好吧，也没发现规律。

其实，到这里，我完全可以把这个问题交给sys那边了，因为已经确定不是我们这边代码的问题了。

  • 检查nginx配置文件相关参数，fastcgi_read_timeout参数设置的是60s，不会导致这个问题。
  • 检查php机器上的php.ini，虽然max_execution_time参数的值是10s，但是我在php的脚本里面使用set_time_limit函数临时将脚本的最长执行时间改为了600s，所以也不是这个问题。
  • 检查php-fpm.conf，request_terminate_timeout参数没有设置，那就是不会限制cgi接口读取数据的时间，php-fpm的问题也被排除了。

到这里我已经开始怀疑人生了。

3. 纠结了3个小时之后，还是丢给sys解决

负责我们组线上机器配置的sys也纠结了两个小时。
最后，终于找到了问题，最近为迎接大促，新上了流控系统，使用的是openresty。
前几天新系统上线的时候就出现了这类问题，但是openresty的配置被多人修改的很乱，有几个地方漏改了。他排查了所有的nginx机器，将

proxy_read_timeout 10s;
proxy_send_timeout 10s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

然后重启openresty，问题解决了。

╮(╯▽╰)╭，纠结死我了，以后这种问题确认不是我们这边代码的问题，直接丢给sys，浪费我这么长时间。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK