php 连接到上游时 nginx php5-fpm 上游超时（110：连接超时）
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5588297/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
nginx php5-fpm upstream timed out (110: Connection timed out) while connecting to upstream
提问by faraklit
We have a web server running with nginx php5-fpm apc setup. However we experienced upstream connection timeout errors and slow downs during page rendering recently. A quick php5-fpm restart fixed the problem but we could not find the cause.
我们有一个运行 nginx php5-fpm apc 设置的网络服务器。但是，我们最近在页面渲染过程中遇到了上游连接超时错误和速度变慢的情况。快速重启 php5-fpm 解决了问题，但我们找不到原因。
We have another web server running apache2 under another subdomain, connecting the same database, doing exact same job. But the slow downs occur only on the nginx-fpm server. I think the php5-fpm or apc may cause the problems.
我们有另一个 web 服务器在另一个子域下运行 apache2，连接同一个数据库，做完全相同的工作。但是速度变慢只发生在 nginx-fpm 服务器上。我认为 php5-fpm 或 apc 可能会导致问题。
Logs tell that various connection time outs:
日志表明各种连接超时：
upstream timed out (110: Connection timed out) while connecting to upstream bla bla bla
upstream timed out (110: Connection timed out) while connecting to upstream bla bla bla
The php5-fpm log does not show anything. Just child starts and finishes:
php5-fpm 日志没有显示任何内容。只是孩子开始和结束：
Apr 07 22:37:27.562177 [NOTICE] [pool www] child 29122 started
Apr 07 22:41:47.962883 [NOTICE] [pool www] child 28346 exited with code 0 after 2132.076556 seconds from start
Apr 07 22:41:47.963408 [NOTICE] [pool www] child 29172 started
Apr 07 22:43:57.235164 [NOTICE] [pool www] child 28372 exited with code 0 after 2129.135717 seconds from start
Server was not loaded when the error occured and load avg was just 2 (2cpus 16cores) and the php5-fpm processes seemed to be working fine.
发生错误时服务器未加载，平均负载仅为 2 (2cpus 16cores)，php5-fpm 进程似乎工作正常。
nginx conf:
nginx配置：
user www-data;
worker_processes 14;
pid /var/run/nginx.pid;
# set open fd limit to 30000
worker_rlimit_nofile 30000;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
nginx enabled site conf:
启用 nginx 的站点配置：
location ~* \.php$ {
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_pass backend;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_intercept_errors off;
fastcgi_ignore_client_abort off;
fastcgi_connect_timeout 20;
fastcgi_send_timeout 20;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
}
## Disable viewing .htaccess & .htpassword
location ~ /\.ht {
deny all;
}
}
upstream backend {
server 127.0.0.1:9000;
}
fpm conf:
fpm 配置：
pm.max_children = 500
pm.start_servers = 100
pm.min_spare_servers = 50
pm.max_spare_servers = 100
pm.max_requests = 10000
There are emergency restart settings in fpm conf file. I do not know if they help us fix the issue?
fpm conf 文件中有紧急重启设置。不知道他们有没有帮我们解决问题？
emergency_restart_interval = 0
回答by Phillip B Oldham
Firstly, reduce the PHP-FPM max_requeststo 100; you want PHP threads to restart much sooner than 10000 req's.
首先，将 PHP-FPM 降低max_requests到 100；您希望 PHP 线程比 10000 个请求更快地重新启动。
Secondly, you've only got one PHP process running with lots of children. This is fine for development, but in production you want to have more PHP processes each with fewer children, so that if that process goes down for any reason there are others which can take up the slack. So, rather than a ratio of 1:50 as you have now, go for a ratio of 10:5. This will be muchmore stable.
其次，您只有一个 PHP 进程与许多子进程一起运行。这对开发来说很好，但在生产中你希望有更多的 PHP 进程，每个进程都有更少的子进程，这样如果该进程由于任何原因出现故障，还有其他进程可以填补空缺。因此，不要像现在这样使用 1:50 的比率，而是选择 10:5 的比率。这样会稳定很多。
To achieve this you may want to look at something like supervisorto manage your PHP processes. We use this in production and it has really helped increase our uptime and reduce the amount of time we spend managing/monitoring the servers. Here's an example of our config:
为了实现这一点，您可能需要查看诸如supervisor 之类的东西来管理您的 PHP 进程。我们在生产中使用它，它确实有助于增加我们的正常运行时间并减少我们花在管理/监控服务器上的时间。这是我们的配置示例：
/etc/php5/php-fpm.conf:
/etc/php5/php-fpm.conf：
[global]
daemonize = no
[www]
listen = /tmp/php.socket
/etc/supervisor.d/php-fpm.conf:
/etc/supervisor.d/php-fpm.conf：
[program:php]
user=root
command=/usr/sbin/php-fpm -c /etc/php5/php.ini -y /etc/php5/php-fpm.conf
numprocs=10
process_name=%(program_name)s
/etc/nginx/conf/php.backend:
/etc/nginx/conf/php.backend：
upstream backend {
server unix:/tmp/php.socket
}
EDIT:
编辑：
As with all server set-ups, don't rely on guess-work to track down where your issues are. I recommend installing Munin along with the various PHP(-FPM) and Nginx plugins; these will help you track hard statistics on requests, response times, memory usage, disk accesses, thread/process levels... all essential when tracking down where the issues are.
与所有服务器设置一样，不要依靠猜测来追踪问题所在。我建议安装 Munin 以及各种 PHP(-FPM) 和 Nginx 插件；这些将帮助您跟踪有关请求、响应时间、内存使用情况、磁盘访问、线程/进程级别的硬统计信息……在跟踪问题所在时，这些都是必不可少的。
In addition, as I mentioned in a comment below, adding both server- and client-side caching to your set-up, even at a modest level, can aid in providing a better experience for users, whether it's using nginx's native caching support or something more specific like varnishd. Even the most dynamic of sites/apps have many static elements which can be held in memory & served faster. Serving these from cache can help reduce the load overall and ensure that those elements which absolutely need to be dynamic have all the resources they need when they need them.
此外，正如我在下面的评论中提到的，将服务器端和客户端缓存添加到您的设置中，即使是在适度的级别，也可以帮助为用户提供更好的体验，无论是使用 nginx 的本机缓存支持还是更具体的东西，比如varnishd。即使是最动态的网站/应用程序也有许多静态元素，可以保存在内存中并更快地提供服务。从缓存中提供这些可以帮助减少整体负载，并确保那些绝对需要动态的元素在需要时拥有所需的所有资源。
