nginx超时的问题(*52081 upstream timed out)

问题提示,在error.log里面的错误提示:2017/04/21 10:17:56 [error] 15588#0: *52206 upstream timed out (110: Connection timed out) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: IP, request: “GET ?action=1 HTTP/1.0”, upstream: “fastcgi://unix:/memdisk/phpfpm.socket”, host: “xxx.xxx.xxx.xxx”, referrer: “xxx”

*52081 upstream timed out

这个错误提示是超时,这里的upstream 就表示php-fcm.

修改nginx.conf的文件,加上超时的判断。
所以,在 http, server 或者 location 的 { 和 } 之间加上这个 directive 并赋予足够高的数值是明智之举,例如:

location ~* .php$ {
include fastcgi_params;
fastcgi_index index.php;
**fastcgi_read_timeout 120;**
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

详细内容取自博客:https://www.bokeyy.com/post/tag/upstream-timed-out

内容备忘:
[翻译]修复 Nginx 和 PHP-FPM 之间的超时问题

本文是 《Fixing timeout between Nginx and PHP-FPM》 的译文。

=======译文开始========

若你使用 Nginx 作为 PHP-FPM 的反向代理,且你的 PHP 脚本很复杂或者很慢,需要运行很久,很可能就会看到 504 gateway time-out 错误。这是个很常见的错误,但是大多数情况下人们会找错解决问题的地方,他们不知道怎么找到哪个超时 directive 是正确的、符合他们的情景的。

原文配图:花五小时修复超时程序,不如用一个 directive 立即解决
原文配图:花五小时修复超时程序,不如用一个 directive 立即解决
我看见很多人拼命的试验 proxy_read_timeout, send_timeout, 甚至 client_header_timeout 和client_body_timeout 的 directive,但如果他们瞥一眼 Nginx 的 error_log,会看到一条类似这样的错误:

2013/01/19 11:36:59 [error] 14564#0: *1215 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 123.456.789.123, server: example.com, request: “POST /path/to/some/script.php HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9000”, host: “example.com”, referrer: “http://example.com/

这条错误清楚的陈述了 Nginx 和 upstream 服务之间的连接超时这件事。在此这个 upstream 服务是 PHP-FPM,但也可以是任何 FastCGI 服务在读响应头时出错。若你据此稍加分析,就不会没找到 fastcgi_read_timeout 这个 directive。浏览文档,看看它是做什么:

设置 upstream 等待 FastCGI 进程发送数据的时长的 directive 。若你有长时间运行、若非结束不输出结果的 FastCGI 进程,修改这个 directive。若你在错误日志中看到 upstream 超时错误,那么增加这个参数到某个更合适的值。
所以,在 http, server 或者 location 的 { 和 } 之间加上这个 directive 并赋予足够高的数值是明智之举,例如:

location ~* .php{  
include fastcgi_params;  
fastcgi_index index.php;  
fastcgi_read_timeout 120;  
fastcgi_pass 127.0.0.1:9000;  
fastcgi_param SCRIPT_FILENAME
document_root$fastcgi_script_name;
}

=======译文结束=======

看到这篇文章是因为 www.yymwz.com 国庆期间莫名其妙 504 gateway time-out 了四天,还顺带连累了同一个服务器上的本站一起 504 了。重启服务什么的都不行。搜索了下,叫我用什么 directive 的都有,而且都号称能解决问题,当然总不见效。最后还是按照这篇文章得到解决。修改了 fastcgi_read_timeout 的 directive 以后,mysql 被拖垮了一次,重启后就正常了,昨天那么久只挂了两次,已经好多了。

不过为什么 PHP 脚本会突然超时,博主我依然是百思不得其解的说。待后续吧。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值