nginxphpfpm優化

『壹』 502 bad gateway nginx怎麼解決

在http協議中，502 狀態碼（Bad Gateway）是指錯誤網關或者無效網關。在nginx中，出現 502 bad gateway則表示nginx代理的upstream模塊發生錯誤或者upstream模塊不可達。

例如，nginx的後端配置的是php作為fastcgi，則當php沒有啟動的時候，訪問時則會出現

502 bad gateway的提示，具體的錯誤信息如下圖所示：

因此，當出現該提示時，應該去檢查nginx的upstream模塊是否正常（例如檢查php是否啟動），如果upstream模塊沒有啟動，則啟動upstream模塊就可以解決。

『貳』 如何正確配置 Nginx + PHP

1. php用php-fpm啟動，然後nginx
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
這樣就可以了
2.安裝一個集成的軟體phpstudy

『叄』 如何在CentOS 6上通過YUM安裝Nginx和PHP-FPM

在CentOS 6上通過YUM安裝Nginx和PHP-FPM：
第一步，在/etc/yum.repos.d/目錄下創建一個源配置文件nginx.repo：
cd /etc/yum.repos.d/
vim nginx.repo

填寫如下內容：
[nginx]
name=nginx repo
baseurl=nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1
保存，則會產生一個/etc/yum.repos.d/nginx.repo文件。

下面直接執行如下指令即可自動安裝好Nginx：
yum install nginx -y
安裝完成，下面直接就可以啟動Nginx了：
/etc/init.d/nginx start
現在Nginx已經啟動了，直接訪問伺服器就能看到Nginx歡迎頁面了的。

『肆』 如何在CentOS 6上通過YUM安裝Nginx和PHP-FPM

1、最好自己編譯，你把思路理順了，按順序來就沒問題。
2、nginx和php沒有編譯先後順序。但是nginx和php都需要准備好先決條件。
3、yum -y install gcc等編譯環境
4、下載所需要的安裝包:
nginx需要pcre-8.13.tar.gz//nginx-1.6.2.tar.gz/zlib-1.2.5.tar.bz2/openssl-1.0.0e.tar.gz
php需要libiconv-1.14.tar.gz/libpng-1.2.46.tar.xz/jpegsrc.v8c.tar.gz/freetype-2.4.6.tar.gz/gd-2.0.35.tar.gz/libxml2-2.7.7.tar.gz/libxslt-1.1.26.tar.gz/libevent-1.4.14b-stable.tar.gz/libevent-2.0.16-stable.tar.gz/libmcrypt-2.5.8.tar.gz/mcrypt-2.6.8.tar.gz/mhash-0.9.9.9.tar.gz/php-5.3.24.tar.gz等

5、php安裝後還需要後期優化，比如：memcache-3.0.6.tgz/ImageMagick-6.6.6-5.tar.gz/imagick-3.0.1.tgz/memcached-1.4.5.tar.gz/eaccelerator-0.9.6.1.tar.bz2/ZendGuardLoader-php-5.3-linux-glibc23-i386.tar.gz
ZendGuardLoader-php-5.3-linux-glibc23-x86_64.tar.gz
6、另外mysql編譯只需要cmake-2.8.8.tar.gz/mysql-5.5.30.tar.gz

『伍』 請教如何配置nginx的fastcgi-cache

1、查看當前的PHP FastCGI進程數是否夠用：
netstat -anpo | grep 「php-cgi」 | wc -l
如果實際使用的「FastCGI進程數」接近預設的「FastCGI進程數」，那麼，說明「FastCGI進程數」不夠用，需要增大。
2、部分PHP程序的執行時間超過了Nginx的等待時間，可以適當增加nginx.conf配置文件中FastCGI的timeout時間
……
http
{
……
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
……
}
……
增加fastcgi_connect_timeout 等三個參數值的方法效果也不好
經過長時間反復測試，發現靜態頁面不會出現該錯誤，只有在運行動態頁面或者長時間操作資料庫時才會出現這個錯誤，重啟Nginx+FastCGI後即可解決，但是幾分鍾到幾個小時後又會出現該錯誤。
經過測試，發現修改php-fpm.conf文件中 request_terminate_timeout即FastCGI腳本運行時間可以有效改善該問題，增加CGI進程數也可以改善該問題，但占資源太多效率太低。
還可以修改
<value name=\「request_terminate_timeout\」>0s</value>
<value name=\「process_control_timeout\」>5s</value>
等值對FastCGI進行優化，所以出現502的錯誤其實不是nginx的問題
php-cgi進程數不夠用、php執行時間長、或者是php-cgi進程死掉，都會出現502錯誤
上面是轉載的，試了裡面的 修改php-fpm.conf文件中 request_terminate_timeou 為3s，試試效果。
我的VPS是256M的內存，CPU是四核心的，所以更多的我會在乎內存。而在我調試伺服器的時候通常會遇到Nginx502 bad gateway和504 Gateway Time-out的錯誤。分析nginx.conf我發現server和fastcgi的buffers過多，導致fastcgi請求的數量過大，php-fpm無法及時處理而出錯。循此思路我們可以再總體buffers不變的情況下減少請求數量，具體的ningx.conf改動細節如下：
server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 1 128k;# 4 32k
client_max_body_size 8m;
sendfile on;
tcp_nopush on;
keepalive_timeout 60;
tcp_nodelay on;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 128k;
fastcgi_buffers 2 256k;#8 128
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;
gzip on;
gzip_min_length 1k;
gzip_buffers 1 64k; #4 16
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
另外，php-fpm的默認靜態處理方式會使得php-cgi的進程長期佔用內存而無法釋放，這也是導致nginx出錯的原因之一，因此可以將php-fpm的處理方式改成apache模式。
<value name=「style」>apache-like</value>
從更改完畢到現在的測試表明上述方式的效果還是很明顯的，並沒有發現一次Nginx502 bad gateway或504 Gateway Time-out錯誤。當然，如果你的VPS或者伺服器的性能足夠好可以根據具體情況不必做無謂的改動。

『陸』 nginx伺服器報502錯誤,重啟伺服器之後網站變慢，查看日誌之後也沒有效果，請問是怎麼一回事

一些運行在Nginx上的網站有時候會出現「502 Bad Gateway」錯誤，有些時候甚至頻繁的出現。一下是搜集整理的一些Nginx 502錯誤的排查方法，供參考：

Nginx 502錯誤的原因比較多，是因為在代理模式下後端伺服器出現問題引起的。這些錯誤一般都不是nginx本身的問題，一定要從後端找原因！但nginx把這些出錯都攬在自己身上了，著實讓nginx的推廣者備受置疑，畢竟從字眼上理解，bad gateway？不就是bad nginx嗎？讓不了解的人看到，會直接把責任推在nginx身上，希望nginx下一個版本會把出錯提示寫稍微友好一些，至少不會是現在簡單的一句 502 Bad Gateway，另外還不忘附上自己的大名。

Nginx 502的觸發條件

502錯誤最通常的出現情況就是後端主機當機。在upstream配置里有這么一項配置：proxy_next_upstream，這個配置指定了 nginx在從一個後端主機取數據遇到何種錯誤時會轉到下一個後端主機，里頭寫上的就是會出現502的所有情況拉，默認是error timeout。error就是當機、斷線之類的，timeout就是讀取堵塞超時，比較容易理解。我一般是全寫上的：

proxy_next_upstream error timeout invalid_header http_500 http_503;不過現在可能我要去掉http_500這一項了，http_500指定後端返回500錯誤時會轉一個主機，後端的jsp出錯的話，本來會列印一堆 stacktrace的錯誤信息，現在被502取代了。但公司的程序員可不這么認為，他們認定是nginx出現了錯誤，我實在沒空跟他們解釋502的原理 了……

503錯誤就可以保留，因為後端通常是apache resin，如果apache死機就是error，但resin死機，僅僅是503，所以還是有必要保留的。

解決辦法

遇到502問題，可以優先考慮按照以下兩個步驟去解決。

1、查看當前的PHP FastCGI進程數是否夠用：

復制代碼 代碼如下:

netstat -anpo | grep "php-cgi" | wc -l

如果實際使用的「FastCGI進程數」接近預設的「FastCGI進程數」，那麼，說明「FastCGI進程數」不夠用，需要增大。

2、部分PHP程序的執行時間超過了Nginx的等待時間，可以適當增加nginx.conf配置文件中FastCGI的timeout時間，例如：

復制代碼 代碼如下:

http { fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; ...... } ......

php.ini中memory_limit設低了會出錯，修改了php.ini的memory_limit為64M，重啟nginx，發現好了，原來是PHP的內存不足了。

如果這樣修改了還解決不了問題，可以參考下面這些方案：

一、max-children和max-requests

一台伺服器上運行著nginx php(fpm) xcache，訪問量日均 300W pv左右。

最近經常會出現這樣的情況：php頁面打開很慢，cpu使用率突然降至很低，系統負載突然升至很高，查看網卡的流量，也會發現突然降到了很低。這種情況只持續數秒鍾就恢復了。

檢查php-fpm的日誌文件發現了一些線索。

復制代碼 代碼如下:

Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200 Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10, 「127.0.0.1:9000″ Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll Sep 30 08:32:23.296426 [NOTICE] fpm_init(), line 47: fpm is running, pid 30587

在這幾句的前面，是1000多行的關閉children和開啟children的日誌。

原來，php-fpm有一個參數 max_requests，該參數指明了，每個children最多處理多少個請求後便會被關閉，默認的設置是500。因為php是把請求輪詢給每個 children，在大流量下，每個childre到達max_requests所用的時間都差不多，這樣就造成所有的children基本上在同一時間 被關閉。

在這期間，nginx無法將php文件轉交給php-fpm處理，所以cpu會降至很低(不用處理php，更不用執行sql)，而負載會升至很高(關閉和開啟children、nginx等待php-fpm)，網卡流量也降至很低(nginx無法生成數據傳輸給客戶端)

解決問題很簡單，增加children的數量，並且將 max_requests 設置未 0 或者一個比較大的值：

打開 /usr/local/php/etc/php-fpm.conf調大以下兩個參數(根據伺服器實際情況，過大也不行）

復制代碼 代碼如下:

<value>5120</value><value>600</value>

然後重啟php-fpm。

二、增加緩沖區容量大小

將nginx的error log打開，發現「pstream sent too big header while reading response header from upstream」這樣的錯誤提示。查閱了一下資料，大意是nginx緩沖區有一個bug造成的,我們網站的頁面消耗佔用緩沖區可能過大。參考老外寫的修 改辦法增加了緩沖區容量大小設置，502問題徹底解決。後來系統管理員又對參數做了調整隻保留了2個設置參數：client head buffer，fastcgi buffer size。

三、request_terminate_timeout

如果主要是在一些post或者資料庫操作的時候出現502這種情況，而不是在靜態頁面操作中常見，那麼可以查看一下php-fpm.conf設置中的一項：

request_terminate_timeout

這個值是max_execution_time，就是fast-cgi的執行腳本時間。

0s

0s為關閉，就是無限執行下去。（當時裝的時候沒仔細看就改了一個數字）問題解決了，執行很長時間也不會出錯了。優化fastcgi中，還可以改改這個值5s 看看效果。

php-cgi進程數不夠用、php執行時間長、或者是php-cgi進程死掉，都會出現502錯誤。Nginx 502 Bad Gateway錯誤的解決辦法2

今天，我的VPS頻繁提示Nginx 502 Bad Gateway錯誤了，重啟了VPS解決之後又出現，很煩。有點想不通，前兩天網站達到了1290的訪問量都沒有出什麼問題，怎麼這次就出現了502 Bad Gateway？郁悶啊！！！在搜索了很久，終於找到了不少相關的答案，希望修改之後不會再出現這個錯誤了。唉，既然在網上找了那麼久的答案，那當然得把有用的東西記錄下，免得我下次再去谷歌~

由於我是採用了LNMP一鍵安裝包 ，出了問題肯定要先到官方論壇去搜索下了，真好，官方有個這樣的置頂帖，大家先瞧瞧。

LNMP一鍵安裝包官方的：

第一種原因：目前lnmp一鍵安裝包比較多的問題就是502 Bad Gateway，大部分情況下原因是在安裝php前，腳本中某些lib包可能沒有安裝上，造成php沒有編譯安裝成功。解決辦法：可以嘗試根據lnmp一鍵安裝包中的腳本手動安裝一下，看看是什麼錯誤導致的。

第二種原因：

在php.ini里，eaccelerator配置項一定要放在Zend Optimizer配置之前，否則也可能引起502 Bad Gateway

第三種原因：

在安裝好使用過程中出現502問題，一般是因為默認php-cgi進程是5個，可能因為phpcgi進程不夠用而造成502，需要修改/usr/local/php/etc/php-fpm.conf 將其中的max_children值適當增加。

第四種原因：

php執行超時，修改/usr/local/php/etc/php.ini 將max_execution_time 改為300

第五種原因：

磁碟空間不足，如mysql日誌佔用大量空間

第六種原因：

查看php-cgi進程是否在運行

也有網友給出了另外的解決辦法：

Nginx 502 Bad Gateway的含義是請求的PHP-CGI已經執行，但是由於某種原因（一般是讀取資源的問題）沒有執行完畢而導致PHP-CGI進程終止，一般來說Nginx 502 Bad Gateway和php-fpm.conf的設置有關。

php-fpm.conf有兩個至關重要的參數，一個是max_children，另一個是request_terminate_timeout，但是這個值不是通用的，而是需要自己計算的。在安裝好使用過程中出現502問題，一般是因為默認php-cgi進程是5個，可能因為phpcgi進程不夠用而造成502，需要修改/usr/local/php/etc/php-fpm.conf 將其中的max_children值適當增加。

計算的方式如下：

如果你的伺服器性能足夠好，且寬頻資源足夠充足，PHP腳本沒有系循環或BUG的話你可以直接將 request_terminate_timeout設置成0s。0s的含義是讓PHP-CGI一直執行下去而沒有時間限制。而如果你做不到這一點，也就 是說你的PHP-CGI可能出現某個BUG，或者你的寬頻不夠充足或者其他的原因導致你的PHP-CGI假死那麼就建議你給 request_terminate_timeout賦一個值，這個值可以根據伺服器的性能進行設定。一般來說性能越好你可以設置越高，20分鍾-30分 鍾都可以。而max_children這個值又是怎麼計算出來的呢？這個值原則上是越大越好，php-cgi的進程多了就會處理的很快，排隊的請求就會很少。 設置max_children也需要根據伺服器的性能進行設定，一般來說一台伺服器正常情況下每一個php-cgi所耗費的內存在20M左右。

按照官方的答案，排查了相關的可能，並結合了網友的答案，得出了下面的解決辦法。

1、查看php fastcgi的進程數（max_children值）

代碼：netstat -anpo | grep 「php-cgi」 | wc -l

5（假如顯示5）

2、查看當前進程

代碼：top觀察fastcgi進程數,假如使用的進程數等於或高於5個，說明需要增加（根據你機器實際狀況而定）

3、調整/usr/local/php/etc/php-fpm.conf 的相關設置

<value name=」max_children」>10</value><value name=」request_terminate_timeout」>60s</value>max_children最多10個進程，按照每個進程20MB內存，最多200MB。request_terminate_timeout執行的時間為60秒，也就是1分鍾。

我現在使用的是小鳥雲伺服器。他們官網最近有活動蠻優惠，建議去看看！

『柒』 nginx和php的兩種通信方式

Nginx與PHP的兩種通信方式-unix socket和tcp socket

1、兩者Nginx配置

unix socket

需要在nginx配置文件中填寫php-fpm運行的pid文件地址。

location ~ \.php$ {

    include fastcgi_params;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;;

    fastcgi_pass unix:/var/run/php5-fpm.sock;

    fastcgi_index index.php;

}

tcp socket

需要在nginx配置文件中填寫php-fpm運行的ip地址和埠號。

location ~ \.php$ {

    include fastcgi_params;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;;

    fastcgi_pass 127.0.0.1:9000;

    fastcgi_index index.php;

}

2、兩者比較

從上面的圖片可以看，unix socket減少了不必要的tcp開銷，而tcp需要經過loopback，還要申請臨時埠和tcp相關資源。但是，unix socket高並發時候不穩定，連接數爆發時，會產生大量的長時緩存，在沒有面向連接協議的支撐下，大數據包可能會直接出錯不返回異常。tcp這樣的面向連接的協議，多少可以保證通信的正確性和完整性。

3、選擇建議：如果是在同一台伺服器上運行的nginx和php-fpm，並發量不超過1000，選擇unix socket，因為是本地，可以避免一些檢查操作(路由等)，因此更快，更輕。 如果面臨高並發業務，我會選擇使用更可靠的tcp socket，以負載均衡、內核優化等運維手段維持效率。

『捌』 nginx php-fpm記錄php錯誤日誌怎麼配置

要想讓php-fpm顯示錯誤日誌，首先需要配置php-fpm。
在php-fpm的配置文件中（一般位於php安裝目錄下的etc/php-fpm.conf）配置php錯誤日誌的文件路徑。

1
2
3
4
5
6

; Error log file
; If it's set to "syslog", log is sent to syslogd instead of being written
; in a local file.
; Note: the default prefix is /home/wangwei/php/var
; Default Value: log/php-fpm.log
;error_log = log/php-fpm.log

如上是我的php-fpm.conf文件中配置錯誤日誌的地方。把error_log = log/php-fpm.log之前的;去掉，然後修改為：

1
2
3
4
5
6

; Error log file
; If it's set to "syslog", log is sent to syslogd instead of being written
; in a local file.
; Note: the default prefix is /home/wangwei/php/var
; Default Value: log/php-fpm.log
error_log = /home/work/log/php-fpm.log.wf

修改之後，保存配置，然後重啟php-fpm就可以啦。
注意如果用相對路徑的話，的路徑的前綴是基於php安裝目錄的var目錄的。

『玖』 伺服器程序源代碼分析之二：php-fpm

php作為排名top2 互聯網開發工具，非常流行，可以參考：中國最大的25個網站採用技術選型方案

php這個名稱實際上有兩層含義

直接定義：

php-fpm從php5.3.3開始已經進入到php源代碼包，之前是作為patch存在的

很少人會去讀php本身源代碼，我6年前解決php內存泄露問題的時候做了些研究,最近再查看了一番，發現php的開發者很有誠意，這是一款非常出色的伺服器軟體，支持如下

在linux伺服器上，如果不設置 events.mechanism ,那麼默認就是採用epoll，所以

php-fpm的IO模型&並發處理能力和nginx是完全一致

nginx以性能卓越聞名，大部分程序員都認為php效率低下，看了源代碼，才知道這是傳奇啊

在高性能部署的時候，大家往往會針對性的優化nginx 。我自己之前部署php程序也犯了錯誤，8G內存的server，php-fpm的max children都會設置128+，現在看來太多了，參考nginx的部署:

php-fpm配置為 3倍 cpu core number就可以了

php-fpm穩定性比nginx稍差 這是因為php-fpm內置了一個php解析器,php-fpm進程就和php程序捆綁了，如果php腳本寫得不好，有死循環或者阻塞在某個遠端資源上，會拖累載入它的php-fpm進程

而nginx和後端應用伺服器之間通過網路連接，可以設置timeout，不容易堵死的

php-fpm的fastcgi是短連接 我原以為是長連接的，看了代碼才知道也是短連接，處理一個request就關閉掉

php-fpm介面採用fastcgi 非常遺憾，php-fpm和fastcgi完全綁定了，無法獨立使用 。只能部署在支持http-fcgi協議轉換程序背後(nginx）。其實可以考慮在php-fpm代碼包裡面引入http協議支持，這樣php-fpm可以獨立運行，讓nodejs無話可說

php-fpm等同於OpenResty OpenResty是一個國人開發的nginx模塊，就是在nginx引入lua解釋器. 實際上，它和php-fpm的唯一差別就是一個採用php語法，一個用lua，所以OpenResty要作為nginx增強包使用還可以，要選擇它作為一個主要編程工具，沒有任何必要

從架構上來說，php-fpm已經做到最好，超過大多數 python部署工具，我再也不黑它了

『拾』 Nginx+PHP-FPM 的怎麼配置讓它支持 RESTFul

這個要看應用項目端具體怎麼實現吧，php不用配置，nginx的重寫需要改一下：
lumen框架的：
location / { try_files $uri $uri/ /index.php?$query_string;}phalcon框架的：
location / { try_files $uri $uri/ /index.php?_url=$uri&$args;}slim 框架的：
location / { try_files $uri $uri/ /index.php$is_args$args;}