nginx的PHP5 - fpm的上游超時（110：連接超時），同時連接到上游

Question

我們有nginx的PHP5 - fpm的APC設定運行的web服務器。 然而，我們的頁面呈現在最近經歷了上游連接超時錯誤和緩慢起伏。一個快速的php5-fpm重啓解決了這個問題，但我們找不到原因。

我們有另一個Web服務器正在運行的Apache2下另一個子域，連接同一個數據庫，這樣做完全一樣的工作。但是緩慢的下降只發生在nginx-fpm服務器上。 我認爲PHP5-FPM或APC可能導致的問題。

日誌告訴各種連接超時：

upstream timed out (110: Connection timed out) while connecting to upstream bla bla bla

的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 

服務器時出現錯誤和負載平均爲僅2（2cpus 16cores）未加載和PHP5-FPM過程似乎是工作的罰款。

的nginx的conf：

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的啓用站點的conf：

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：

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 

Answer 1

首先，PHP-FPM max_requests降低至100;您希望PHP線程重啓的時間早於10000請求。

其次，你只有一個PHP進程運行很多孩子。這對於開發來說很好，但是在生產中你希望有更多的PHP進程，每個進程都有更少的子進程，所以如果進程因任何原因停止運行，還有其他可能會導致進程的進程。所以，而不是像現在這樣1:50的比例，去比例爲10：5。這將是多更穩定。

要達到此目的，您可能需要查看諸如supervisor之類的內容來管理您的PHP進程。我們在生產中使用它，它確實幫助我們延長了正常運行時間，並減少了我們花費在管理/監控服務器上的時間。下面是我們配置的例子：

/etc/php5/php-fpm.conf：

[global] 
daemonize = no 

[www] 
listen = /tmp/php.socket 

/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。後端：

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

編輯：

與所有服務器設置窗口，不靠猜測工作來跟蹤您的問題。我建議安裝Munin以及各種PHP（-FPM）和Nginx插件;這些將幫助您追蹤有關請求，響應時間，內存使用情況，磁盤訪問，線程/進程級別等的硬統計信息......在追蹤問題出現的位置時，這一切都非常重要。另外，正如我在下面的評論中提到的，即使在適當的級別添加服務器端和客戶端緩存，也可以幫助爲用戶提供更好的體驗，無論是使用nginx的本地緩存支持或更特定的東西，如varnishd。即使是最具活力的網站/應用程序也有很多靜態元素，可以在內存中保存更快的服務。從緩存中提供這些內容可以幫助減少總體負載，並確保那些絕對需要動態的元素在需要時擁有所需的全部資源。