轉載至: https://www.cnblogs.com/kenshinobiy/p/7470635.html
PHP-FPM配置及使用總結：
php-FPM是一個PHP FastCGI的管理器，它實際上就是PHP源代碼的補丁，旨在將FastCGI進程管理引進到PHP軟件包中，我們必須將其patch到PHP源代碼中，然后再行編譯才能使用。而現在我們可以在PHP 5.3.2及更新版本中直接開啟並使用即可，因為PHP從該版本已經將其收入到軟件包中，所以其不再是補丁包的存在了。
· 幾個概念的理解
· Nginx+PHP配置
· Php-Fpm的操作
一、幾個概念的理解
1）、CGI
CGI全稱“公共網關接口”(Common Gateway Interface)，是HTTP服務器與其它機器上的程序進行通信的接口，其程序須運行在網絡服務器上。
NOTE:
CGI可以用任何一種語言編寫，只要這種語言具有標准輸入、輸出和環境變量。
2）、FastCGI
FastCGI是一個常駐型的CGI，它可以一直執行，只要激活后，不會每次都要花費時間去fork一次（這是CGI最為人詬病的fork-and-execute模式）。它還支持分布式的運算，即 FastCGI 程序可以在網站服務器以外的主機上執行並且接受來自其它網站服務器來的請求。
FastCGI是語言無關的、可伸縮架構的CGI開放擴展，其主要行為是將CGI解釋器進程保持在內存中並因此獲得較高的性能。我們知道，CGI解釋器的反復加載是CGI性能低下的主要原因，如果CGI解釋器保存在內存中並接受FastCGI進程管理器調度，那么就可以提供良好的性能、伸縮性等。
優點：
1. FastCGI具有語言無關性；
2. FastCGI獨立於核心web服務器運行，提供了一個比API更安全的環境。APIs把應用程序的代碼與核心的web服務器鏈接在一起，這意味着在一個錯誤的API的應用程序可能會損壞其他應用程序或核心服務器。而惡意的API的應用程序代碼甚至可以竊取另一個應用程序或核心服務器的密鑰；
3. FastCGI技術目前支持語言有：C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等。相關模塊在Apache, ISS, Lighttpd等流行的服務器上也是可用的；
4. FastCGI不依賴於任何Web服務器的內部架構，因此即使服務器技術的變化, FastCGI依然穩定不變；
缺點：
因為是多進程，所以比CGI多線程消耗更多的服務器內存，PHP-CGI解釋器每進程消耗7至25兆內存，將這個數字乘以50或100就是很大的內存數。
Nginx 0.8.46+PHP 5.2.14(FastCGI)服務器在3萬並發連接下，開啟的10個Nginx進程消耗150M內存（15M*10=150M），開啟的64個php-cgi進程消耗1280M內存（20M*64=1280M），加上系統自身消耗的內存，總共消耗不到2GB內存。如果服務器內存較小，完全可以只開啟25個php-cgi進程，這樣php-cgi消耗的總內存數才500M。
上面的數據摘自Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建勝過Apache十倍的Web服務器(第6版)。
原理：
1. Web服務器啟動時，載入FastCGI進程管理器；
2. FastCGI進程管理器初始化，啟動多個CGI解釋器進程(PHP-CGI)並等待來自Web服務器的連接；
3. 當客戶端請求到達Web服務器時，FastCGI進程管理器選擇並連接到一個CGI解釋器，Web服務器將CGI環境變量和標准輸入發送到FastCGI子進程PHP-CGI。
4. FastCGI子進程完成處理后將標准輸出和錯誤信息從同一連接返回給Web服務器。當FastCGI子進程關閉連接時，請求便告處理完成。FastCGI子進程接着等待並處理來自FastCGI進程管理器(運行在Web服務器中)的下一個連接。而在CGI模式中，PHP-CGI在此便退出了。
在上述情況中，可以想象CGI通常有多慢，每一個Web請求PHP都必須重新解析php.ini、重新載入全部擴展，並重初始化全部數據結構。而使用FastCGI，所有這些都只在進程啟動時發生一次。另外，數據庫持久連接可以工作。
NOTE:
FastCGI的主要優點是把動態語言和HTTP Server分離開來，所以Nginx與PHP/PHP-FPM經常被部署在不同的服務器上，以分擔前端Nginx服務器的壓力，使Nginx專一處理靜態請求和轉發動態請求，而PHP/PHP-FPM服務器專一解析PHP動態請求。
3）、PHP-CGI
PHP-CGI是PHP自帶的FastCGI管理器。
PHP-CGI的不足：
1. php-cgi變更php.ini配置后需重啟php-cgi才能讓新的php-ini生效，不可以平滑重啟。
2. 直接殺死php-cgi進程，php就不能運行了(PHP-FPM和Spawn-FCGI就沒有這個問題，守護進程會平滑重新生成新的子進程)。
4）、Spawn-FCGI
Spawn-FCGI是一個通用的FastCGI管理服務器，它是lighttpd中的一部份，很多人都用Lighttpd的Spawn-FCGI進行FastCGI模式下的管理工作，不過有不少缺點。而PHP-FPM的出現多少緩解了一些問題，但PHP-FPM有個缺點就是要重新編譯，這對於一些已經運行的環境可能有不小的風險(refer)，在php 5.3.3可以直接使用PHP-FPM了。
Spawn-FCGI目前已經獨成為一個項目，更加穩定一些，也給很多Web 站點的配置帶來便利。已經有不少站點將它與nginx搭配來解決動態網頁。最新的lighttpd也沒有包含這一塊了(http://www.lighttpd.NET/search?q=Spawn-FCGI)，但可以在以前版本中找到它。在lighttpd-1.4.15
版本中就包含了(http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz)，目前Spawn-FCGI的下載地址是http://redmine.lighttpd.Net/projects/spawn-fcgi，最新版本是http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz。
NOTE：
最新的Spawn-FCGI可以到lighttpd.net網站搜索“Spawn-FCGI”找到它的最新版本發布地址。
5）、對比Spawn-FCGI
PHP-FPM的使用非常方便，配置都是在PHP-FPM.ini的文件內，而啟動、重啟都可以從php/sbin/PHP-FPM中進行。更方便的是修改php.ini后可以直接使用PHP-FPM reload進行加載，無需殺掉進程就可以完成php.ini的修改加載
結果顯示使用PHP-FPM可以使php有不小的性能提升。PHP-FPM控制的進程cpu回收的速度比較慢,內存分配的很均勻。
Spawn-FCGI控制的進程CPU下降的很快，而內存分配的比較不均勻。有很多進程似乎未分配到，而另外一些卻占用很高。可能是由於進程任務分配的不均勻導致的。而這也導致了總體響應速度的下降。而PHP-FPM合理的分配，導致總體響應的提到以及任務的平均。
二、Nginx+PHP配置
1、進程數優化
pm = dynamic 【表示使用哪種進程數量管理方式】
dynamic表示php-fpm進程數是動態的，最開始是pm.start_servers指定的數量，如果請求較多，則會自動增加，保證空閑的進程數不小於pm.min_spare_servers，如果進程數較多，也會進行相應清理，保證多余的進程數不多於pm.max_spare_servers
static表示php-fpm進程數是靜態的, 進程數自始至終都是pm.max_children指定的數量，不再增加或減少
pm.max_children = 300 【靜態方式下開啟的php-fpm進程數量】
pm.start_servers = 20 【動態方式下的起始php-fpm進程數量】
pm.min_spare_servers = 5 【動態方式下的最小php-fpm進程數量】
pm.max_spare_servers = 35 【動態方式下的最大php-fpm進程數量】
如果pm為static, 那么其實只有pm.max_children這個參數生效。系統會開啟設置數量的php-fpm進程
如果pm為dynamic, 那么pm.max_children參數失效，后面3個參數生效。系統會在php-fpm運行開始的時候啟動pm.start_servers個php-fpm進程，然后根據系統的需求動態在pm.min_spare_servers和pm.max_spare_servers之間調整php-fpm進程數
那么，對於我們的服務器，選擇哪種pm方式比較好呢？事實上，跟Apache一樣，運行的PHP程序在執行完成后，或多或少會有內存泄露的問題。這也是為什么開始的時候一個php-fpm進程只占用3M左右內存，運行一段時間后就會上升到20-30M的原因了。
對於內存大的服務器（比如8G以上）來說，指定靜態的max_children實際上更為妥當，因為這樣不需要進行額外的進程數目控制，會提高效率。因為頻繁開關php-fpm進程也會有時滯，所以內存夠大的情況下開靜態效果會更好。數量也可以根據 內存/30M 得到，比如8GB內存可以設置為100，那么php-fpm耗費的內存就能控制在 2G-3G的樣子。如果內存稍微小點，比如1G，那么指定靜態的進程數量更加有利於服務器的穩定。這樣可以保證php-fpm只獲取夠用的內存，將不多的內存分配給其他應用去使用，會使系統的運行更加暢通。
對於小內存的服務器來說，比如256M內存的VPS，即使按照一個20M的內存量來算，10個php-cgi進程就將耗掉200M內存，那系統的崩潰就應該很正常了。因此應該盡量地控制php-fpm進程的數量，大體明確其他應用占用的內存后，給它指定一個靜態的小數量，會讓系統更加平穩一些。或者使用動態方式，因為動態方式會結束掉多余的進程，可以回收釋放一些內存，所以推薦在內存較少的服務器或VPS上使用。具體最大數量根據 內存/20M 得到。比如說512M的VPS，建議pm.max_spare_servers設置為20。至於pm.min_spare_servers，則建議根據服務器的負載情況來設置，比較合適的值在5~10之間。
在4G內存的服務器上200就可以(我的1G測試機，開64個是最好的，建議使用壓力測試獲取最佳值)
2、最大請求數優化
pm.max_requests = 10240
nginx php-fpm配置過程中最大問題是內泄漏出問題：服務器的負載不大，但是內存占用迅速增加，很快吃掉內存接着開始吃交換分區，系統很快掛掉！其實根據官方的介紹，php-cgi不存在內存泄漏，每個請求完成后php-cgi會回收內存，但是不會釋放給操作系統，這樣就會導致大量內存被php-cgi占用。
官方的解決辦法是降低PHP_FCGI_MAX_REQUESTS的值，如果用的是php-fpm，對應的php-fpm.conf中的就是max_requests，該值的意思是發送多少個請求后會重啟該線程，我們需要適當降低這個值，用以讓php-fpm自動的釋放內存，不是大部分網上說的51200等等，實際上還有另一個跟它有關聯的值max_children，這個是每次php-fpm會建立多少個進程，這樣實際上的內存消耗是max_children*max_requests*每個請求使用內存，根據這個我們可以預估一下內存的使用情況，就不用再寫腳本去kill了。
NOTE:
這個用來處理因為PHP解析器或引用的第三方庫時，造成的內存泄露問題。
最大請求數：指一個php-fpm的工作進程在處理多少個請求后就終止掉。
3、最長執行時間優化（php.ini）
request_terminate_timeout = 20
NOTE:
這個是用來處理因為PHP執行時間超長而報502錯誤的解決。
這個時長配置可以在php.ini（max_execution_time）或php-fpm.conf中配置均可，為了不影響全局配置，可在php-fpm.conf中實現。
值得注意的是：需要結合nginx.conf中的max_fail（調大些）和fail_timeout（調小些）一同配置。
nginx.conf:
location ~ \.php$ {
…
fastcgi_connect_timeout 180;
fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
…
}
NOTE:
PHP-FPM設置的腳本最大執行時間已經夠長了，但執行耗時PHP腳本時，發現Nginx報錯變為504錯誤。這是因為我們修改的只是PHP的配置，Nginx中也有關於與上游服務器通信超時時間的配置factcgi_connect/read/send_timeout。
4、php-fpm高cpu使用排查
top命令 :
直接執行top命令后，輸入1就可以看到各個核心的CPU使用率:
sar命令：
sar和iostat命令的安裝：
sysstat.x86_64 : The sar and iostat systemmonitoring commands
yum install -y sysstat.x86_64
執行：
$sar -P ALL 1 100
NOTE:
-P ALL表示監控所有核心;
1表示每1秒采集;
100表示采集100次;
5、開啟慢日志
slowlog = log/$pool.log.slow
request_slowlog_timeout = 2
NOTE:
上面為開啟php-fpm的慢日志，時間閥值2秒；
執行：
grep -v "^$" php.slow.log | cut -d " " -f 3,2 | sort |uniq -c | sort -k1,1nr | head -n 50
NOTE:
sort: 對單詞進行排序
uniq -c: 顯示唯一的行，並在每行行首加上本行在文件中出現的次數
sort -k1,1nr: 按照第一個字段，數值排序，且為逆序
head –n 10: 取前10行數據
PS:
開啟慢日志的目的是為了跟蹤分析那條php腳本執行的時間超過了設置的request_slowlog_timeout時長，如果超過這個設置時間，那么該腳本就會被記錄下。
三、Php-Fpm的操作
PHP5.3.3下的php-fpm 不再支持php-fpm 以前具有的 /usr/local/php/sbin/php-fpm(start|stop|reload)等命令，需要使用信號控制：
master進程可以理解以下信號
INT, TERM 立刻終止 ;
QUIT 平滑終止 ;
USR1 重新打開日志文件 ;
USR2平滑重載所有worker進程並重新載入配置和二進制模塊 ;
示例：
php-fpm 關閉： kill -INT`cat /usr/local/php/var/run/php-fpm.pid`
php-fpm 重啟： kill -USR2`cat /usr/local/php/var/run/php-fpm.pid`
查看php-fpm進程數：
$ps aux | grep -c php-fpm