问题提示，在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_FILENAMEdocument_root$fastcgi_script_name;
}
=======译文结束=======
看到这篇文章是因为 www.yymwz.com 国庆期间莫名其妙 504 gateway time-out 了四天，还顺带连累了同一个服务器上的本站一起 504 了。重启服务什么的都不行。搜索了下，叫我用什么 directive 的都有，而且都号称能解决问题，当然总不见效。最后还是按照这篇文章得到解决。修改了 fastcgi_read_timeout 的 directive 以后，mysql 被拖垮了一次，重启后就正常了，昨天那么久只挂了两次，已经好多了。
不过为什么 PHP 脚本会突然超时，博主我依然是百思不得其解的说。待后续吧。