Tcp 连接到上游时，nginx php5 fpm上游超时（110：连接超时）

我们有一个运行nginx php5 fpm apc设置的web服务器。 但是，我们最近在页面呈现期间遇到了上游连接超时错误和速度减慢。快速重启php5 fpm修复了问题，但我们无法找到原因

我们有另一个web服务器在另一个子域下运行apache2，连接同一个数据库，执行完全相同的工作。但减速只发生在nginx fpm服务器上。 我认为php5 fpm或apc可能会导致问题

日志显示各种连接超时：

连接到上游bla bla bla时上游超时（110：连接超时）

php5 fpm日志没有显示任何内容。Just child开始和结束：

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

发生错误时服务器未加载，平均加载量仅为2（2cpus 16核），php5 fpm进程似乎工作正常

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的站点配置：

    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形态：

pm.max_children = 500
pm.start_servers = 100
pm.min_spare_servers = 50
pm.max_spare_servers = 100
pm.max_requests = 10000

fpm conf文件中有紧急重启设置。 我不知道他们是否帮助我们解决这个问题

emergency_restart_interval = 0

---

首先，将PHP-FPM

max_请求减少到100；您希望PHP线程比10000个req更快地重新启动

其次，您只有一个PHP进程运行，并且有很多子进程。这对于开发来说是很好的，但是在生产中，您希望有更多的PHP进程，每个进程都有更少的子进程，因此，如果该进程因任何原因而停止，那么其他进程可以填补这一空缺。所以，不要像你现在的比例是1:50，而是选择10:5的比例。这将更加稳定

要实现这一点，您可能需要研究一些类似于管理PHP进程的方法。我们在生产中使用它，它确实有助于增加我们的正常运行时间，减少我们管理/监控服务器的时间。下面是我们的配置示例：

/etc/php5/php fpm.conf:

[global]
daemonize = no

[www]
listen = /tmp/php.socket

[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

upstream backend {
    server unix:/tmp/php.socket
}

/etc/supervisor.d/php fpm.conf:

[global]
daemonize = no

[www]
listen = /tmp/php.socket

[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

upstream backend {
    server unix:/tmp/php.socket
}

/etc/nginx/conf/php.backend:

[global]
daemonize = no

[www]
listen = /tmp/php.socket

[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

upstream backend {
    server unix:/tmp/php.socket
}

编辑：

[global]
daemonize = no

[www]
listen = /tmp/php.socket

[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

upstream backend {
    server unix:/tmp/php.socket
}

与所有服务器设置一样，不要依赖猜测工作来跟踪问题所在。我建议安装Munin以及各种PHP（-FPM）和Nginx插件；这些将帮助您跟踪有关请求、响应时间、内存使用、磁盘访问、线程/进程级别的硬统计信息。。。在追踪问题所在时，所有这些都至关重要

此外，正如我在下面的评论中提到的，在设置中同时添加服务器端和客户端缓存，即使是在一个适度的级别上，也可以帮助为用户提供更好的体验，无论是使用nginx的本机缓存支持，还是使用varnishd等更具体的功能。即使是最具动态性的网站/应用程序也有许多静态元素，可以保存在内存中并更快地提供服务。从缓存中提供这些服务有助于降低总体负载，并确保绝对需要动态的元素在需要时拥有所需的所有资源。
fpm.conf中的侦听选项如何？是9000端口吗？当然。听我说谢谢你，我会试试你的建议。我认为较小的max_请求会导致不必要的进程终止/创建开销。如果我们创建更多的父php进程和单独的php进程，APC会受到影响吗？我们暂时不使用socket，以防我们使用另一个专用服务器来处理php。如果您使用的是nginx+php fpm，您不需要使用单独的服务器来处理php；使用varnishd调整nginx/php和缓存将更有效率。PHP在短期内工作得更好；这就是它的设计目的，所以重启是件好事。APC不应该受到影响。如果答案有用的话，别忘了接受它！；-）numprocs=10 10 10个进程共享相同的APC shm？关于tcp问题，如果需要提供太多的页面（每天10-20M），该怎么办？当然，我会接受，只要我尝试，它解决了我们的问题。；）我真的不会担心APC；更多的进程可能意味着更多的内存使用，但这很好，因为您将成功地提供更多的页面！至于死亡；PHP有一个最大250个内置请求的硬限制。我们发现，当PHP达到这个硬限制时，它通常可以在回收时接受REQ，导致这些REQ挂起/失败。降低限制可以解决这个问题，同时为nginx提供多个后端，如果nginx没有及时得到响应，就可以故障转移到另一个后端/proc。试试看；使用Munin+nginx/fpm插件监控结果，并与当前设置进行比较。此外，如果您担心每天提供1000-2000万页的服务，那么您真的应该尽可能地缓存所有内容。PHP+APC不会达到varnish可以达到的吞吐量，即使缓存时间很短；BBC iPlayer网站会在很短的时间（1-5分钟）内缓存页面，但即使是这种适度的缓存水平也会大大降低服务器上的负载。通过巧妙/积极的缓存策略，您可以通过适度的硬件设置轻松达到您提到的级别。缓存——这是未来！