linux中php-fpm進程數最佳化與分析詳解

在幾個不是很繁忙的線上伺服器發現php-fpm進程數達到500多，且存在一些已耗用時間長達幾個月的進程。

進行了以下排查，以確定：phpfpm運行是否有問題，是否需要重啟。

查看這些進程是否被正常啟動

由於php-fpm.log中，會以notice層級列印worker進程的啟動和回收時間，故可以通過以下語句檢查有哪些php沒有被記錄到（ps axuf可以查看到進程的父子關係）：

代碼如下	複製代碼
$cd /path/to/php-fpm.log $for word in `ps axu | grep php | perl -ne 'chomp; @tmp=split " +", $_; print $tmp[1]."n";'` ; do  if grep $word php-fpm.log >/dev/null ; then echo -n ''; else echo $word;  fi ; done

執行結果，發現有173個進程未被記錄，一部分有可能是在php-fpm父進程啟動時，直接fork出來的，所以未記錄。但還剩餘幾十個，我也不知道啥原因了。

確認進程是否存活

通過root帳號登入上去，strace -p <pid>，其中pid是上面173個進程之一。發現正常滾動，並能看到對php方法的調用，故確定該進程存活，且可以提供服務。

為什麼有這麼多進程存在呢？

雖然對服務沒有影響，但這麼多進程存在，是否正常呢？

首先得看下php-fpm.conf：

代碼如下	複製代碼
pm = dynamic pm.max_children = 8192 pm.start_servers = 128 pm.min_spare_servers = 128 pm.max_spare_servers = 1024 pm.max_requests = 500000

 

由於我們的空閑進程配置為128 ～ 1024，而max_request配置為50w，並且之前機器流量不大，所以可能很長一段時間，進程都不會因為處理完了max_request個請求、或者超過了spare_servers個數 而被回收。

而一個php-fpm進程佔用12m左右非共用記憶體，根據機器配置，cpu、記憶體配置來看，支援1k個php-fpm進程是足夠的。

約定幾個目錄

代碼如下	複製代碼
/usr/local/php/sbin/php-fpm /usr/local/php/etc/php-fpm.conf /usr/local/php/etc/php.ini

一，php-fpm的啟動參數

 

代碼如下

複製代碼

#測試php-fpm配置 /usr/local/php/sbin/php-fpm -t /usr/local/php/sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf -t   #啟動php-fpm /usr/local/php/sbin/php-fpm /usr/local/php/sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf   #關閉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.conf重要參數詳解

代碼如下

複製代碼

pid = run/php-fpm.pid #pid設定，預設在安裝目錄中的var/run/php-fpm.pid，建議開啟   error_log = log/php-fpm.log #錯誤記錄檔，預設在安裝目錄中的var/log/php-fpm.log   log_level = notice #錯誤層級. 可用層級為: alert（必須立即處理）, error（錯誤情況）, warning（警告情況）, notice（一般重要訊息）, debug（調試資訊）. 預設: notice.   emergency_restart_threshold = 60 emergency_restart_interval = 60s #表示在emergency_restart_interval所設值內出現SIGSEGV或者SIGBUS錯誤的php-cgi進程數如果超過 emergency_restart_threshold個，php-fpm就會優雅重啟。這兩個選項一般保持預設值。   process_control_timeout = 0 #設定子進程接受主進程複用訊號的逾時時間. 可用單位: s(秒), m(分), h(小時), 或者 d(天) 預設單位: s(秒). 預設值: 0.   daemonize = yes #後台執行fpm,預設值為yes，如果為了調試可以改為no。在FPM中，可以使用不同的設定來運行多個進程池。 這些設定可以針對每個進程池單獨設定。   listen = 127.0.0.1:9000 #fpm監聽連接埠，即nginx中php處理的地址，一般預設值即可。可用格式為: 'ip:port', 'port', '/path/to/unix/socket'. 每個進程池都需要設定.   listen.backlog = -1 #backlog數，-1表示無限制，由作業系統決定，此行注釋掉就行。backlog含義參考：http://www.3gyou.cc/?p=41   listen.allowed_clients = 127.0.0.1 #允許訪問FastCGI進程的IP，設定any為不限制IP，如果要設定其他主機的nginx也能訪問這台FPM進程，listen處要設定成本地可被訪問的IP。預設值是any。每個地址是用逗號分隔. 如果沒有設定或者為空白，則允許任何伺服器請求串連   listen.owner = www listen.group = www listen.mode = 0666 #unix socket設定選項，如果使用tcp方式訪問，這裡注釋即可。   user = www group = www #啟動進程的帳戶和組   pm = dynamic #對於專用伺服器，pm可以設定為static。 #如何控制子進程，選項有static和dynamic。如果選擇static，則由pm.max_children指定固定的子進程數。如果選擇dynamic，則由下開參數決定： pm.max_children #，子進程最大數 pm.start_servers #，啟動時的進程數 pm.min_spare_servers #，保證空閑進程數最小值，如果空閑進程小於此值，則建立新的子進程 pm.max_spare_servers #，保證空閑進程數最大值，如果空閑進程大於此值，此進行清理   pm.max_requests = 1000 #設定每個子進程重生之前服務的請求數. 對於可能存在記憶體流失的第三方模組來說是非常有用的. 如果設定為 '0' 則一直接受請求. 等同於 PHP_FCGI_MAX_REQUESTS 環境變數. 預設值: 0.   pm.status_path = /status #FPM狀態頁面的網址. 如果沒有設定, 則無法訪問狀態頁面. 預設值: none. munin監控會使用到   ping.path = /ping #FPM監控頁面的ping網址. 如果沒有設定, 則無法訪問ping頁面. 該頁面用於外部檢測FPM是否存活並且可以響應請求. 請注意必須以斜線開頭 (/)。   ping.response = pong #用於定義ping請求的返回相應. 返回為 HTTP 200 的 text/plain 格式文本. 預設值: pong.   request_terminate_timeout = 0 #設定單個請求的逾時中止時間. 該選項可能會對php.ini設定中的'max_execution_time'因為某些特殊原因沒有中止啟動並執行指令碼有用. 設定為 '0' 表示 'Off'.當經常出現502錯誤時可以嘗試更改此選項。   request_slowlog_timeout = 10s #當一個請求該設定的逾時時間後，就會將對應的PHP呼叫堆疊資訊完整寫入到慢日誌中. 設定為 '0' 表示 'Off'   slowlog = log/$pool.log.slow #慢請求的記錄日誌,配合request_slowlog_timeout使用   rlimit_files = 1024 #設定檔案開啟描述符的rlimit限制. 預設值: 系統定義值預設可開啟控制代碼是1024，可使用 ulimit -n查看，ulimit -n 2048修改。   rlimit_core = 0 #設定核心rlimit最大限制值. 可用值: 'unlimited' 、0或者正整數. 預設值: 系統定義值.   chroot = #啟動時的Chroot目錄. 所定義的目錄需要是絕對路徑. 如果沒有設定, 則chroot不被使用.   chdir = #設定啟動目錄，啟動時會自動Chdir到該目錄. 所定義的目錄需要是絕對路徑. 預設值: 目前的目錄，或者/目錄（chroot時）   catch_workers_output = yes #重新導向運行過程中的stdout和stderr到主要的錯誤記錄檔檔案中. 如果沒有設定, stdout 和 stderr 將會根據FastCGI的規則被重新導向到 /dev/null . 預設值: 空.

三，常見錯誤及解決辦法整理

1,request_terminate_timeout引起的資源問題

request_terminate_timeout的值如果設定為0或者過長的時間，可能會引起file_get_contents的資源問題。

如果file_get_contents請求的遠端資源如果反應過慢，file_get_contents就會一直卡在那裡不會逾時。我們知道php.ini 裡面max_execution_time 可以設定 PHP 指令碼的最大執行時間，但是，在 php-cgi(php-fpm) 中，該參數不會起效。真正能夠控制 PHP 指令碼最大執行時間的是 php-fpm.conf 設定檔中的request_terminate_timeout參數。

request_terminate_timeout預設值為 0 秒，也就是說，PHP 指令碼會一直執行下去。這樣，當所有的 php-cgi 進程都卡在 file_get_contents() 函數時，這台 Nginx+PHP 的 WebServer 已經無法再處理新的 PHP 請求了，Nginx 將給使用者返回“502 Bad Gateway”。修改該參數，設定一個 PHP 指令碼最大執行時間是必要的，但是，治標不治本。例如改成 30s，如果發生 file_get_contents() 擷取網頁內容較慢的情況，這就意味著 150 個 php-cgi 進程，每秒鐘只能處理 5 個請求，WebServer 同樣很難避免”502 Bad Gateway”。解決辦法是request_terminate_timeout設定為10s或者一個合理的值，或者給file_get_contents加一個逾時參數。

代碼如下	複製代碼
$ctx = stream_context_create(array(     'http' => array(         'timeout' => 10    //設定一個逾時時間，單位為秒     ) ));   file_get_contents($str, 0, $ctx);

2,max_requests參數配置不當，可能會引起間歇性502錯誤：

代碼如下	複製代碼
pm.max_requests = 1000

設定每個子進程重生之前服務的請求數. 對於可能存在記憶體流失的第三方模組來說是非常有用的. 如果設定為 ’0′ 則一直接受請求. 等同於 PHP_FCGI_MAX_REQUESTS 環境變數. 預設值: 0.
這段配置的意思是，當一個 PHP-CGI 進程處理的請求數累積到 500 個後，自動重啟該進程。

但是為什麼要重啟進程呢？

一般在項目中，我們多多少少都會用到一些 PHP 的第三方庫，這些第三方庫經常存在記憶體流失問題，如果不定期重啟 PHP-CGI 進程，勢必造成記憶體使用量量不斷增長。因此 PHP-FPM 作為 PHP-CGI 的管理器，提供了這麼一項監控功能，對請求達到指定次數的 PHP-CGI 進程進行重啟，保證記憶體使用量量不增長。

正是因為這個機制，在高並發的網站中，經常導致 502 錯誤，我猜測原因是 PHP-FPM 對從 NGINX 過來的請求隊列沒處理好。不過我目前用的還是 PHP 5.3.2，不知道在 PHP 5.3.3 中是否還存在這個問題。

目前我們的解決方案是，把這個值盡量設定大些，儘可能減少 PHP-CGI 重新 SPAWN 的次數，同時也能提高總體效能。在我們自己實際的生產環境中發現，記憶體流失並不明顯，因此我們將這個值設定得非常大（204800）。大家要根據自己的實際情況設定這個值，不能盲目地加大。

話說回來，這套機制目的只為保證 PHP-CGI 不過分地佔用記憶體，為何不通過檢測記憶體的方式來處理呢？我非常認同高春輝所說的，通過設定進程的峰值內在佔用量來重啟 PHP-CGI 進程，會是更好的一個解決方案。

3,php-fpm的慢日誌，debug及異常排查神器：

代碼如下	複製代碼
request_slowlog_timeout設定一個逾時的參數，slowlog設定慢日誌的存放位置 1 tail -f /var/log/www.slow.log

上面的命令即可看到執行過慢的php過程。
大家可以看到經常出現的網路讀取超過、Mysql查詢過慢的問題，根據提示資訊再排查問題就有很明確的方向了。
啟動參數及重要配置

php-fpm最佳化

1、php-fpm最佳化參數介紹

他們分別是：pm、pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers。

pm：表示使用那種方式，有兩個值可以選擇，就是static（靜態）或者dynamic（動態）。
在更老一些的版本中，dynamic被稱作apache-like。這個要注意看設定檔的說明。

下面4個參數的意思分別為：

pm.max_children：靜態方式下開啟的php-fpm進程數量
pm.start_servers：動態方式下的起始php-fpm進程數量
pm.min_spare_servers：動態方式下的最小php-fpm進程數
pm.max_spare_servers：動態方式下的最大php-fpm進程數量
區別：

如果dm設定為 static，那麼其實只有pm.max_children這個參數生效。系統會開啟設定數量的php-fpm進程。
如果dm設定為 dynamic，那麼pm.max_children參數失效，後面3個參數生效。
系統會在php-fpm運行開始 的時候啟動pm.start_servers個php-fpm進程，
然後根據系統的需求動態在pm.min_spare_servers和pm.max_spare_servers之間調整php-fpm進程數

2、伺服器具體配置

對於我們的伺服器，選擇哪種執行方式比較好呢？事實上，跟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，則建議根據伺服器的負載情況來設定，比如伺服器上只是部署php環境的話，比較合適的值在5~10之間。

本伺服器配置

1、伺服器基本資料：

硬碟：資料盤30G、系統硬碟20G
記憶體：1.5G
CPU：雙核
系統：CentOS 6.3 64位
頻寬：獨享2M

2、部署的應用

Git、SVN、Apache、Tomcat、PHP、Nginx、Mysql、JDK

3、最佳化後的參數

代碼如下	複製代碼
pm = dynamic pm.start_servers = 5 pm.min_spare_servers = 2 pm.max_spare_servers = 8

php5.3.3以後php-fpm進程管理方式

PHP-FPM提供了更好的PHP進程管理方式，可以有效控制記憶體和進程、可以平滑重載PHP配置，比spawn-fcgi具有更多優點，所以被PHP官方收錄了。在php5.3.3 以後./configure的時候帶 –enable-fpm參數即可開啟PHP-FPM。

使用PHP-FPM來控制PHP-CGI的FastCGI進程

代碼如下	複製代碼
/usr/local/php/sbin/php-fpm{start|stop|quit|restart|reload|logrotate} 　　--start 啟動php的fastcgi進程 　　--stop 強制終止php的fastcgi進程 　　--quit 平滑終止php的fastcgi進程 　　--restart 重啟php的fastcgi進程 　　--reload 重新平滑載入php的php.ini 　　--logrotate 重新啟用log檔案

php-fpm目前主要又兩個分支，分別對應於php-5.3.3以前的版本和php-5.3.3以後的版本。在5.2.x的版本中，php-fpm.conf使用的是xml格式，而在新的5.3.3以後的版本中，則是php.ini一樣的配置風格。對於5.5.3以後的版本中存在兩種php-fpm進程的管理方式——static和dynamic。具體/usr/local/php/conf/php-fpm.conf.default中的配置如下：

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives. With this process management, there will be
;             always at least 1 children.
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
;  ondemand - no children are created at startup. Children will be forked when
;             new requests will connect. The following parameter are used:
;             pm.max_children           - the maximum number of children that
;                                         can be alive at the same time.
;             pm.process_idle_timeout   - The number of seconds after which
;                                         an idle process will be killed.
; Note: This value is mandatory.
pm = dynamic

      從上面可以看到預設是啟用的動態管理方式。而php-fpm進程數是動態，最開始是pm.start_servers指定的數量，如果請求較多，則會自動增加，保證閒置進程數不小於pm.min_spare_servers，如果進程數較多，也會進行相應清理，保證多餘的進程數不多於pm.max_spare_servers。在上面的設定檔中也可以看到其中涉及到四個參數的設定，其作用分別如下：
pm.max_children：靜態方式下開啟的php-fpm進程數量。
pm.start_servers：動態方式下的起始php-fpm進程數量。
pm.min_spare_servers：動態方式下的最小php-fpm進程數量。
pm.max_spare_servers：動態方式下的最大php-fpm進程數量。

如果dm設定為static，那麼其實只有pm.max_children這個參數生效。系統會開啟設定數量的php-fpm進程。
如果dm設定為dynamic，那麼pm.max_children參數失效，後面3個參數生效。系統會在php-fpm運行開始的時候啟動pm.start_servers個php-fpm進程，然後根據系統的需求動態在pm.min_spare_servers和pm.max_spare_servers之間調整php-fpm進程數。

那麼，對於我們的伺服器，選擇哪種執行方式比較好呢？事實上，跟Apache一樣，啟動並執行PHP程式在執行完成後，或多或少會有記憶體泄露的問題。這也是為什麼開始的時候一個php-fpm進程只佔用3M左右記憶體，運行一段時間後就會上升到20-30M的原因了。

對於記憶體大的伺服器（比如8G以上）來說，指定靜態max_children實際上更為妥當，因為這樣不需要進行額外的進程數目控制，會提高效率。因為頻繁開關php-fpm進程也會有時滯，所以記憶體夠大的情況下開靜態效果會更好。比如8GB記憶體可以設定為100，那麼php-fpm耗費的記憶體就能控制在 2G-3G的樣子。，如果資料庫和web應用在不同的伺服器上，該機器只跑web應用，大可開到300左右。如果記憶體稍微小點，比如1G那麼指定靜態進程數量更加有利於伺服器的穩定。這樣可以保證php-fpm只擷取夠用的記憶體，將不多的記憶體配置給其他應用去使用，會使系統的運行更加暢通。

對於小記憶體的伺服器來說，比如256M記憶體的VPS，即使按照一個20M的記憶體量來算，10個php-cgi進程就將耗掉200M記憶體，那系統的崩潰就應該很正常了。因此應該盡量地控制php-fpm進程的數量，大體明確其他應用佔用的記憶體後，給它指定一個靜態小數量，會讓系統更加平穩一些。或者使用動態方式，因為動態方式會結束掉多餘的進程，可以回收釋放一些記憶體，所以推薦在記憶體較少的伺服器或VPS上使用。比如說512M的VPS，建議pm.max_spare_servers設定為20。至於pm.min_spare_servers，則建議根據伺服器的負載情況來設定，比較合適的值在5~10之間。