一、背景

早上突然發(fā)現服務器這邊所有的請求都報錯：502，具體報錯信息如下：

connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: xxx, server: xxx, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "xxx"

這個意思是無法找到php5-fpm.sock，但是原來是好好的，為什么會出現這種問題呢？

二、第一種可能

1、第一種可能就是，nginx配置的問題：

nginx配置文件中有一句是這樣的，監(jiān)聽sock文件 fastcgi_pass unix:/var/run/php5-fpm.sock;

2、解決方案

進入 /etc/php5/fpm/pool.d/www.conf，修改配置，里面找到這樣一段代碼：

``` listen = 127.0.0.1:9000 ```在這上面代碼的下面添加一行：``` listen = /var/run/php5-fpm.sock ```保存后啟動php5-fpm``` /etc/init.d/php5-fpm restart ```這時就可以正常訪問了

三、第二種可能

1、既然是報錯502，眾所周知，這個錯誤代表的意思就是：

???????這個錯誤是由于服務器壓力過大，不能及時處理client的請求導致服務器響應超時而拋出的錯誤。通俗來講，我們向服務器發(fā)送請求 由于服務器當前鏈接太多，導致服務器方面無法給于正常的響應,產生此類報錯。

???????那么OK，因為我們使用的是php-fpm的系統服務，那么極有可能是我們在給服務器請求的時候，由于請求量比較大，php-fpm在規(guī)定的響應時間內沒有響應，自動殺掉這些進程或者卡死造成的。

2、解決方案

1）增大請求的持續(xù)時間，防止php腳本或者php-fpm自動殺死進程

//修改php.ini 中的參數，可以把這個參數設置的大一些， 代表置了腳本被解析器中止之前允許的最大執(zhí)行時間 ，默認是30s。也就是說這個請求如果30s還沒得到響應的話 ，腳本會自動殺死這個請求。 max_execution_time = 60s

???????如果不想修改php.ini文件的話，可以選擇修改php-fpm.conf文件，因為在服務器正常運行的時候，php-fpm.conf中的request_terminate_timeout 會覆蓋php.ini中的max_execution_time

request_terminate_timeout = 60s #表示等待60秒后，結束那些沒有自動結束的php腳本，以釋放占用的資源。 當PHP運行在php-fpm模式下，php.ini配置的max_execute_time是無效的，需要在php-fpm.conf中配置另外一個配置項:request_terminate_timeout;

???????如果你的服務器性能足夠好，且寬帶資源足夠充足，PHP腳本沒有系循環(huán)或BUG的話你可以直接將”request_terminate_timeout”設置成0s。0s的含義是讓PHP-CGI一直執(zhí)行下去而沒有時間限制。而如果你做不到這一點，也就是說你的PHP-CGI可能出現某個BUG，或者你的寬帶不夠充足或者其他的原因導致你的PHP-CGI能夠假死那么就建議你給”request_terminate_timeout”賦一個值，這個值可以根據你服務器的性能進行設定。一般來說性能越好你可以設置越高，20分鐘-30分鐘都可以。由于我的服務器PHP腳本需要長時間運行，有的可能會超過10分鐘因此我設置了900秒，這樣不會導致PHP-CGI死掉而出現502 Bad gateway這個錯誤。

PS：這個部分，我的php-fpm.conf中并沒有這個參數，因此我是自己加上去的。

2)修改php-fpm給子進程分配的時間間隔

這里修改的是php-fpm.conf中的 process_control_timeout 參數

解釋：php-fpm和FastCGI的關系：

???????關于process_control_timeout項配置的由來及詳細介紹，依靠CGI接口，Nginx把收到的請求轉給PHP，并從PHP獲得返回數據，但CGI實現邏輯是一次請求建立一個PHP進程，處理結束的同時關閉php進程，而php進程的每次啟動銷毀都很耗資源，于是出現了FastCGI的方式，一個fastcgi進程可以處理多個請求再關閉，但FastCGI依然有缺點，因為fastcgi是單個進程串行，即同一時刻只能處理一個請求，于是php-fpm就出現了，它的作用就是可以管理多個fastcgi。從而實現同時處理多個請求。php-fpm就和nginx的主進程一樣，而每一個處理請求的php進程就像是nginx里的多個執(zhí)行線程。這就是php進程的復用。php-fpm作為一個調度員，會自動讓空閑的FastCGI進程去處理請求，但是在分配請求給php進程前，PHP-FPM需要發(fā)送一個進程復用信號給FastCGI，以讓FastCGI準備請求處理。但是FastCGI進程并不總是能夠處理請求，也就是不能夠響應進程復用信號，這個參數就表示了PHP-FPM留給FastCGI進程多久時間去響應進程復用信號，如果超時PHP-FPM會選擇其他的fastcgi去處理。這段也是從網上找到的，以我的理解進行了一些修改。從英文注釋來看，這個配置是子進程等待主進程的超時時間。可能和上面的描述有細微的出入，但也不妨對功能進行理解。

process_control_timeout = 20

???????通過以上的描述，我們就知道了，設置這個參數相當于給程序更多的響應時間，以免出現502的情況。

3） 修改php-fpm自動重啟的時間

這里需要修改的參數還是php-fpm.conf中的參數：

#表示在emergency_restart_interval所設值內出現SIGSEGV或者SIGBUS錯誤的php-cgi進程數如果 #超過emergency_restart_threshold個php-fpm就會優(yōu)雅重啟。這兩個選項一般保持默認值emergency_restart_threshold = 60 emergency_restart_interval = 30s

???????這兩個參數的意思就是在30秒內出現SIGSEGV或者SIGBUS錯誤的php-cgi進程數超過60個，則會自動重啟php-fpm。

這里的emergency_restart_threshold是需要根據自己的服務器性能來計算的，計算方式為：

比如一個fastcgi進程占用的內存為30M，則1G的服務器，最大能設置的值為 1024/30 = 34 但實際上我們不可能把所有的內存都用來出來這些東西，所以設置成30是比較合適的。

end

參考鏈接：
php-fpm.conf重要參數詳解

php-fpm超時時間設置request_terminate_timeout分析

php-fpm參數調優(yōu)

總結

以上是生活随笔為你收集整理的nginx报错502：connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。