我们在 AWS 上运行一个网站,设置如下:ELB 将负载分摊到 2 个运行 nginx 的 t2.medium 实例上。从那里,PHP 流量被分成 2 个(前端和 API)流,均流向 PHP 服务器前端的内部 ELB。顺便说一下,我们有 2 个前端 PHP 服务器(t2.medium)和 3 个 API PHP 服务器(m4.large)。所有服务器都在端口 9000 上运行相同版本的 PHP-FPM。
直到几天前,一切都运行良好。由于某种尚未确定的原因,PHP API 服务器上的流量突然中断,只有重新启动 nginx 才能恢复。
我们假设可能有一些长时间运行的进程导致其中一个 PHP 服务器变得繁忙,然后一切都会从那里开始走下坡路。但是,所有 PHP 服务器上的 CPU 使用率都相当稳定,直到它们停止响应为止。PHP-FPM 仍在运行,ngnix 服务器上的负载仍然很低。客户端收到的响应为 504,这是我在 nginx 错误日志中看到的内容:
2016/10/04 14:34:25 [error] 17661#0: *2309784 connect() failed (113: No route to host) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: api.mywebsite.com, request: "GET /some/route HTTP/1.1", upstream: "fastcgi://internalip:9000", host: "api.mywebsite.com"
nginx.conf
worker_processes 4;
worker_connections 19000;
nginx 站点配置
location ~ \.php$ {
try_files $uri =404;
fastcgi_buffer_size 512k;
fastcgi_buffers 16 256k;
fastcgi_busy_buffers_size 1024k;
include fastcgi_params;
fastcgi_pass route53-php:9000;
fastcgi_index index.php;
fastcgi_param REQUEST_URI /api$request_uri;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
閣下網站
listen = 9000
pm = dynamic
pm.max_children = 50
pm.start_servers = 25
pm.min_spare_servers = 25
pm.max_spare_servers = 25
pm.max_requests = 500
由于设置过程并不简单,我怀疑 PHP 位置块是否设置正确。也可能是所用服务器的大小,但 CPU 使用率很低。
答案1
是的,事实证明这是 nginx 与 AWS 内部 ELB 通信时的一个常见问题。经过一番谷歌搜索,我发现了这个问题:某些 nginx 反向代理配置每天停止工作一次添加解析器很有帮助——我已经 3 天没有遇到任何停机时间了。
值得一提的是,我发现的每篇文章都在谈论代理密码但似乎效果很好fastcgi_pass也一样。
希望这能对处于同样境况的人有所帮助!