1. 程式人生 > >nginx服務器下 PHP 出現 502 解決方案

nginx服務器下 PHP 出現 502 解決方案

影響 有一個 roo fin owin 訪問 帳號 bad 一點

https://blog.csdn.net/qq_34625397/article/details/51744859

nginx出現502有很多原因,但大部分原因可以歸結為資源數量不夠用,也就是說後端php-fpm處理有問題,nginx將正確的客戶端請求發給了後端的php-fpm進程,但是因為php-fpm進程的問題導致不能正確解析php代碼,最終返回給了客戶端502錯誤。

nginx+php出現502 bad gateway,一般這都不是nginx的問題,而是由於 fastcgi或者php的問題導致的,常見的有以下幾種(其實解決問題的最好的方式還是自己去看nginx和fastcgi的errorlog):

1. php.ini的memory_limit 過小(如果有個別php程序進程需要占用極大內存時這個必須註意)

2. php-fpm.conf中max_children或者max_requests 設置不合理(設置過小會因為沒有足夠的cgi進程處理請求,設置過大會出現一會兒有響應正常,一會兒等很久才有響應的情況,一般情況下children按 照內存計算,比如說1G設置64,2G128。這個根據實際情況自行調整。另外查看當前的PHP FastCGI進程數是否夠用的命令為:netstat -anpo |grep “php-cgi” | wc -l 如果實際使用的“FastCGI進程數”接近預設的“FastCGI進程數”,那麽,說明“FastCGI進程數”不夠用,需要增大。)

3. 查看nginx錯誤日誌,發現 pstream sent too big header while reading response headerfrom upstream ,則檢查client head buffer,fastcgi buffer size是否過小,可設置為32K。

4. php程序執行時間過長而超時,檢查nginx和fastcgi中各種timeout設置。(nginx 中的 fastcgi_connect_timeout 300;fastcgi_send_timeout 300 :fastcgi_read_timeout300; keepalive_timeout ; php-fpm中的request_terminate_timeout,php.ini中的max_execution_time)

5. php-fpm有一個參數 max_requests ,該參數指明了每個children最多處理多少個請求後便會被關閉。在大量處理請求下,如果該值設置過小會導致children頻繁的自殺和建立而浪費 大量時間,若所有的children差不多都在這個時候自殺,則重建前將沒有children響應請求,於是出現502 。可以將該值設置大一些或者是0[無限]。

如果你服務器並發量非常大,那只能先增加機器,然後按以下方式優化會取得更好效果;但如果你並發不大卻出現502,一般都可以歸結為配置問題,腳本超時問題。

1.php-fpm進程數不夠用

使用netstat -napo |grep "php-fpm" | wc -l查看一下當前fastcgi進程個數,如果個數接近conf裏配置的上限,就需要調高進程數。

但也不能無休止調高,可以根據服務器內存情況,可以把php-fpm子進程數調到100或以上,在4G內存的服務器上200就可以。

2. 調高調高linux內核打開文件數量

可以使用這些命令(必須是root帳號)

echo ‘ulimit -HSn 65536‘>> /etc/profile

echo ‘ulimit -HSn 65536‘>> /etc/rc.local

source /etc/profile

3.腳本執行時間超時

如果腳本因為某種原因長時間等待不返回,導致新來的請求不能得到處理,可以適當調小如下配置。

nginx.conf裏面主要是如下

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

php-fpm.conf裏如要是如下

request_terminate_timeout =10s

4.緩存設置比較小

修改或增加配置到nginx.conf

proxy_buffer_size 64k;
proxy_buffers 512k;
proxy_busy_buffers_size 128k;

5. recv()failed (104: Connection reset by peer) while reading response header fromupstream

可能的原因機房網絡丟包或者機房有硬件防火墻禁止訪問該域名

但最重要的是程序裏要設置好超時,不要使用php-fpm的request_terminate_timeout,

最好設成request_terminate_timeout=0;

因為這個參數會直接殺掉php進程,然後重啟php進程,這樣前端nginx就會返回104: Connection reset by peer。這個過程是很慢,總體感覺就是網站很卡。

May 01 10:50:58.044162[WARNING] [pool www] child 4074, script‘/usr/local/nginx/html/quancha/sameip/detail.php‘ execution timed out(15.129933 sec), terminating
May 01 10:50:58.045725 [WARNING] [pool www] child 4074 exited on signal 15SIGTERM after 90.227060 seconds from start
May 01 10:50:58.046818 [NOTICE] [pool www] child 4082 started

說一千道一萬最重要的就是程序裏控制好超時,gethostbyname、curl、file_get_contents等函數的都要設置超時時間。

另一個就是多說,這個東西是增加了網站的交互性,但是使用的多了反應就慢了,如果你網站超時且使用了多說是,可以關閉它。

6、自己遇到502的解決辦法:

調整增大php 和Nginx 的backlog數。

PHP-FPM高負載的解決辦法

Postedon 2011/09/02

這裏只是介紹了php-fpm的優化方法的,但一般情況下和nginx組合使用的時候,單獨優化其中一項的話,作用不是特別的大,同時還需要對nginx進行優化.nginx的做法方法參考:http://blog.haohtml.com/archives/6213.上面的優化前和優化後的圖,看得出前後差距還是特別的大的.

導致nginx 502 bad gateway的PHP-CGI(FASTCGI)

NGINX頻爆502 BAD GATEWAY的錯誤,看了網上的教程,仍沒有徹底解決。
目前我總結的解決502 BAD GATEWAY的方式有:

1.視服務器的性能,在php-fmp.conf裏增加max_children的值:

max_children是PHP-FPM Pool 最大的子進程數,他數值取決於你的服務器內存。 假設你打算給10G內存給當前配置的PHP-FPM Pool,一般一個PHP請求占用內存10M-40M,我們按站點每個PHP請求占用內存25M,這樣max_children = 10G/25M = 409。所以,這個值可以根據情況算出來

max_requests是每個子進程重生之前處理的請求數, 默認值為unlimited(默認為1024),可以設置小一點(如500左右),這樣可以避免內存泄露帶來的問題

Nginx代理過程,將業務服務器請求數據緩存到本地文件,再將文件數據轉發給請求客戶端。高並發的客戶端請求,必然要求服務器文件句柄的並發打開限制。使用ulimit命令(ulimit -n),查看Linux系統文件句柄並發限制,默認是1024,我們可以改為65535(2 的 16 次方,這是系統端口的極限)。修改的方法為:修改系統文件/etc/security/limits.conf,添加如下信息,並重新啟動系統生效。

* soft   nofile  65535

* hard   nofile  65535

然後在Nginx配置文件中,把文件限制及連接數信息改為65535:

worker_rlimit_nofile 65535;
events {
    use epoll;
    worker_connections  65535;
}

2.用reload參數定時重載php-fpm。這個主要原因是php腳本執行時間過長造成的,重載php-fpm能杜絕這個問題。如何徹底解決php-cgi腳本占用大量內存從而導致502錯誤的產生還值得進一步探討,目前該做法不失為一種好辦法。
具體的做法是,用crontab讓php-fpm平滑重啟,從而不影響PHP腳本的運行。

*/10* * * * /usr/local/php/sbin/php-fpm reload

=================== 優化設置=========================

如果您高負載網站使用PHP-FPM管理FastCGI,這些技巧也許對您有用:)

1.Compile PHP’s modules as less as possible, the simple the best (fast);
1.盡量少安裝PHP模塊,最簡單是最好(快)的

2. Increas PHP FastCGI child number to 100 and even more.Sometime, 200 is OK! ( On 4GB memory server);

2.把您的PHP FastCGI子進程數調到100或以上,在4G內存的服務器上200就可以
註:我的1g測試機,開64個是最好的,建議使用壓力測試獲取最佳值

3.Using SOCKET PHP FastCGI, and put into /dev/shm on Linux;
3.使用socket連接FastCGI,linux操作系統可以放在/dev/shm中
註:在php-fpm.cnf裏設置<valuename=”listen_address”>/tmp/nginx.socket</value>就可以通過socket連接FastCGI了,/dev/shm是內存文件系統,放在內存中肯定會快了.記得這時也要在nginx裏的配置裏進行修改,保持一致.

location~ .*/.(php|php5)?$

{

#

將Nginx與FastCGI的通信方式由TCP改為UnixSocket。TCP在高並發訪問下比UnixSocket穩定,但Unix Socket速度要比TCP快。

fastcgi_pass unix:/tmp/php-cgi.sock;

#fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fcgi.conf;

}

4. Increase Linux “max open files”, using the following command(must be root):

# echo ‘ulimit -HSn 65536′>> /etc/profile

# echo ‘ulimit -HSn 65536 >> /etc/rc.local

# source /etc/profile


4.調高linux內核打開文件數量,可以使用這些命令(必須是root帳號

)

echo ‘ulimit -HSn 65536′ >> /etc/profile

echo ‘ulimit -HSn 65536′ >> /etc/rc.local

source /etc/profile


註:我是修改/etc/rc.local,加入ulimit -SHn 51200的

5.Increase PHP-FPM open file description rlimit:

# vi /path/to/php-fpm.conf

Find “<value name=”rlimit_files”>1024</value>”

Change 1024 to 4096 or higher number.

Restart PHP-FPM.


5.增加 PHP-FPM 打開文件描述符的限制

# vi /path/to/php-fpm.conf

找到

“<value name=”rlimit_files”>1024</value>”

把1024更改為4096或者更高

.

重啟PHP-FPM.

6. Using PHP code accelerator,e.g eAccelerator, XCache. And set “cache_dir” to /dev/shm on Linux.
6.使用php代碼加速器,例如eAccelerator, XCache.在linux平臺上可以把`cache_dir`指向/dev/shm

參考文章:

https://myjeeva.com/php-fpm-configuration-101.html

https://stackoverflow.com/questions/21524373/nginx-connect-failed-111-connection-refused-while-connecting-to-upstream

http://niutuku.com/tech/php/273616.shtml

nginx服務器下 PHP 出現 502 解決方案