PHPfpm管理

A. php-fpm這個事幹嘛用的為什麼要開啟

PHP-FPM(FastCGI Process Manager:FastCGI進程管理器)是一個PHPFastCGI管理器，對於PHP 5.3.3之前的php來說，是一個補丁包 ，旨在將FastCGI進程管理整合進PHP包中。如果你使用的是PHP5.3.3之前的PHP的話，就必須將它patch到你的PHP源代碼中，在編譯安裝PHP後才可以使用。
相對Spawn-FCGI，PHP-FPM在CPU和內存方面的控制都更勝一籌，而且前者很容易崩潰，必須用crontab進行監控，而PHP-FPM則沒有這種煩惱。

B. php-fpm的工作機制

概括來說，fpm 的實現就是創建一個 master 進程，在 master 進程中創建並監聽 socket，然後 fork 出多個子進程，這些子進程各自 accept 請求，子進程的處理非常簡單，它在啟動後阻塞在 accept 上，有請求到達後開始讀取請求數據，讀取完成後開始處理然後再返回，在這期間是不會接收其它請求的，也就是說 fpm 的子進程同時只能響應一個請求，只有把這個請求處理完成後才會 accept 下一個請求，這一點與 nginx 的事件驅動有很大的區別，nginx 的子進程通過 epoll 管理套接字，如果一個請求數據還未發送完成則會處理下一個請求，即一個進程會同時連接多個請求，它是非阻塞的模型，只處理活躍的套接字。

fpm 的 master 進程與 worker 進程之間不會直接進行通信，master 通過共享內存獲取 worker 進程的信息，比如 worker 進程當前狀態、已處理請求數等，當 master 進程要殺掉一個 worker 進程時則通過發送信號的方式通知 worker 進程。

fpm 可以同時監聽多個埠，每個埠對應一個 worker pool，而每個 pool 下對應多個 worker 進程，類似 nginx 中 server 概念。

在 php-fpm.conf 中通過[pool name]聲明一個 worker pool：

啟動 fpm 後查看進程：

具體實現上 worker pool 通過fpm_worker_pool_s這個結構表示，多個 worker pool 組成一個單鏈表

接下來看下 fpm 的啟動流程，從main()函數開始：

fpm_init()主要有以下幾個關鍵操作：

(1) fpm_conf_init_main():

解析 php-fpm.conf 配置文件，分配 worker pool 內存結構並保存到全局變數中：fpm_worker_all_pools，各 worker pool 配置解析到fpm_worker_pool_s->config中。

(2)fpm_scoreboard_init_main():

分配用於記錄 worker 進程運行信息的共享內存，按照 worker pool 的最大 worker 進程數分配，每個 worker pool 分配一個fpm_scoreboard_s結構，pool 下對應的每個 worker 進程分配一個fpm_scoreboard_proc_s結構。
(3)fpm_signals_init_main():

這里會通過socketpair()創建一個管道，這個管道並不是用於 master 與 worker 進程通信的，它只在 master 進程中使用，具體用途在稍後介紹 event 事件處理時再作說明。另外設置 master 的信號處理 handler，當 master 收到 SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT 這些信號時將調用sig_handler()處理：

(4)fpm_sockets_init_main()

創建每個 worker pool 的 socket 套接字。
(5)fpm_event_init_main():

啟動 master 的事件管理，fpm 實現了一個事件管理器用於管理 IO、定時事件，其中 IO 事件通過 kqueue、epoll、poll、select 等管理，定時事件就是定時器，一定時間後觸發某個事件。

在fpm_init()初始化完成後接下來就是最關鍵的fpm_run()操作了，此環節將 fork 子進程，啟動進程管理器，另外 master 進程將不會再返回，只有各 worker 進程會返回，也就是說fpm_run()之後的操作均是 worker 進程的。

在 fork 後 worker 進程返回了監聽的套接字繼續 main() 後面的處理，而 master 將永遠阻塞在fpm_event_loop()，接下來分別介紹 master、worker 進程的後續操作。

fpm_run()執行後將 fork 出 worker 進程，worker 進程返回main()中繼續向下執行，後面的流程就是 worker 進程不斷 accept 請求，然後執行 PHP 腳本並返回。整體流程如下：

worker 進程一次請求的處理被劃分為 5 個階段：

worker 處理到各個階段時將會把當前階段更新到fpm_scoreboard_proc_s->request_stage，master 進程正是通過這個標識判斷 worker 進程是否空閑的。

接下來我們來看下 master 是如何管理 worker 進程的，首先介紹下三種不同的進程管理方式：

前面介紹到在fpm_run()中 master 進程將進入fpm_event_loop()：

這就是 master 整體的處理，其進程管理主要依賴注冊的幾個事件，接下來我們詳細分析下這幾個事件的功能。

(1)sp[1]管道可讀事件：

在 fpm_init() 階段 master 曾創建了一個全雙工的管道：sp，然後在這里創建了一個 sp[0] 可讀的事件，當 sp[0] 可讀時將交由 fpm_got_signal() 處理，向 sp[1] 寫數據時 sp[0] 才會可讀，那麼什麼時機會向 sp[1] 寫數據呢？前面已經提到了：當 master 收到注冊的那幾種信號時會寫入 sp[1] 端，這個時候將觸發 sp[0] 可讀事件。

這個事件是 master 用於處理信號的，我們根據 master 注冊的信號逐個看下不同用途：

具體處理邏輯在 fpm_got_signal() 函數中，這里不再羅列。

(2)fpm_pctl_perform_idle_server_maintenance_heartbeat():

這是進程管理實現的主要事件，master 啟動了一個定時器，每隔 1s 觸發一次，主要用於 dynamic、ondemand 模式下的 worker 管理，master 會定時檢查各 worker pool 的 worker 進程數，通過此定時器實現 worker 數量的控制，處理邏輯如下：

(3)fpm_pctl_heartbeat():

這個事件是用於限制 worker 處理單個請求最大耗時的，php-fpm.conf 中有一個request_terminate_timeout的配置項，如果 worker 處理一個請求的總時長超過了這個值那麼 master 將會向此 worker 進程發送kill -TERM信號殺掉 worker 進程，此配置單位為秒，默認值為 0 表示關閉此機制，另外 fpm 列印的 slow log 也是在這里完成的。

除了上面這幾個事件外還有一個沒有提到，那就是 ondemand 模式下 master 監聽的新請求到達的事件，因為 ondemand 模式下 fpm 啟動時是不會預創建 worker 的，有請求時才會生成子進程，所以請求到達時需要通知 master 進程，這個事件是在fpm_children_create_initial()時注冊的，事件處理函數為fpm_pctl_on_socket_accept()，具體邏輯這里不再展開，比較容易理解。

原文出處： https://www.fanhao.com/2017/10/internal-php-fpm.html

C. php-fpm的介紹

PHP-FPM是一個PHPFastCGI管理器，是只用於PHP的。

D. phpfpm工作原理～呢

進程池管理工具，簡單描述，nginx將收到的php相關請求轉發到phpfpm，由phpfpm負責生成和管理php進程來執行相應的php腳本，並將結果返回給nginx。

E. php-fpm的簡介

PHP-FPM(FastCGI Process Manager：FastCGI進程管理器)對於PHP 5.3.3之前的php來說，是一個補丁包 ，旨在將FastCGI進程管理整合進PHP包中。如果你使用的是PHP5.3.3之前的PHP的話，就必須將它patch到你的PHP源代碼中，在編譯安裝PHP後才可以使用。
從PHP 5.4 RC2開始，php-fpm已經轉正了，不再被php團隊標注為EXPERIMENTAL（實驗性的東西） 。
相對Spawn-FCGI，PHP-FPM在CPU和內存方面的控制都更勝一籌，而且前者很容易崩潰，必須用crontab進行監控，而PHP-FPM則沒有這種煩惱。
PHP5.3.3已經集成php-fpm了，不再是第三方的包了。PHP-FPM提供了更好的PHP進程管理方式，可以有效控制內存和進程、可以平滑重載PHP配置，比spawn-fcgi具有更多優點，所以被PHP官方收錄了。在./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文件

F. PHP中的FPM是做什麼的

FPM（FastCGI 進程管理器）用於替換 PHP FastCGI 的大部分附加功能，對於高負載網站是非常有用的。它的功能包括：

• 支持平滑停止/啟動的高級進程管理功能；

• 可以工作於不同的 uid/gid/chroot 環境下，並監聽不同的埠和使用不同的 php.ini 配置文件（可取代 safe_mode 的設置）；

• stdout 和 stderr 日誌記錄;

• 在發生意外情況的時候能夠重新啟動並緩存被破壞的 opcode;

• 文件上傳優化支持;

• "慢日誌" - 記錄腳本（不僅記錄文件名，還記錄 PHP backtrace 信息，可以使用 ptrace或者類似工具讀取和分析遠程進程的運行數據）運行所導致的異常緩慢;

• fastcgi_finish_request() - 特殊功能：用於在請求完成和刷新數據後，繼續在後台執行耗時的工作（錄入視頻轉換、統計處理等）；

• 動態／靜態子進程產生；

• 基本 SAPI 運行狀態信息（類似Apache的 mod_status）；

• 基於 php.ini 的配置文件。

G. 如何啟用 Apache 的 PHP-FPM 多實例

php-fpm的兩種進程管理模式
php-fpm的進程數也是可以根據設置分為動態和靜態的。
一種是直接開啟指定數量的php-fpm進程，不再增加或者減少；
另一種則是開始的時候開啟一定數量的php-fpm進程，當請求量變大的時候，動態的增加php-fpm進程數到上限，當空閑的時候自動釋放空閑的進程數到一個下限。
這兩種不同的執行方式，可以根據伺服器的實際需求來進行調整。
這里先說一下涉及到這個的幾個參數吧，他們分別是pm、pm.max_children、pm.start_servers、pm.min_spare_servers和pm.max_spare_servers。
pm表示使用那種方式，有兩個值可以選擇，就是static（靜態）或者dynamic（動態）。你也可以到後盾人去看看相關的程序視頻，會對你有幫助

H. php-fpm的FAQ

Q：php-fpm 可以和 ZendOptimize 一起用嗎？
A：完全可以。
Q：php-fpm 可以和 ZendPlatform、xcache、eAccelerator、APC 等的優化器一起用嗎？
A：是的。php-fpm 的架構和任何一種用於高速 opcode 緩存的共享內存都適用。唯一的限制是：所有的 worker 進程只能適用一個緩存，即使它們用不同的 uid/gid 運行
Q：為什麼我要給php打補丁呢？spawn-fcgi 不需要這樣！
A：php-fpm 的創建是為了增強方便管理。沒有打過補丁的php不能做到：
平滑重啟php而不丟失請求，包括升級 php二進制文件以及/或者 擴展。
用不同的 uid / gid / chroot 環境運行 worker 進程
所有的設置只有一個配置文件
根據負載動態請求 （TODO）
對php請求實時統計性能 （TODO）
Q：為什麼要用 root 運行php-fpm 呢？這安全嗎？
A：用 root 啟動php-fpm 只有在你打算用不同 uid/gid 的 php 來處理請求時才有意義。比如，在共享主機上的不同站點。因為只有在 master 進程用 root 運行的時候，才可以建立不同 uid/gid 的子進程。這是相當安全的。master 進程自己從來不會去處理請求。
在任何情況下，php-fpm 都不會用 root 身份來處理請求。
Q：php-fpm 可以加速 php 腳本處理速度嗎？
A：不，它不會影響處理速度。不過，如果你使用一些特殊特性，對於一些特定的請求還是可以有性能提升的。
Q：如果我把我的網站從 mod_php遷移到php-fpm ，我會得到性能提升嗎？
A：通常，當有伺服器上有大量空閑內存可用時，能從遷移到 php-fpm 中得到的性能提升可能不大。但是如果內存並不充裕，性能提升還是很可觀的，在某些情況下可以達到 300-500%。這可能是由於 nginx +php-fpm 一般會比 Apache + mod_php 使用更少的內存。而且 VFS 緩存會由於更多的空餘內存而更有效地工作。
Q：php-fpm 將來會被官方的 php 包含嗎？
A：我希望如此。php-fpm 代碼採用的是GPL許可證 。所以現在php-fpm 的代碼與 php 協議（類似BSD許可證）並不匹配 。這是臨時性措施。這樣的選擇是為了簡化開發過程。一旦代碼的功能完備，比如自適應生成子進程和其他一些東西，協議會改為一個相匹配的。之後，php-fpm 會正式發布給 php 開發團隊，並被建議包含。

I. php升級php-fpm配置怎麼設置

PHP-FPM是一個PHP FastCGI的管理器，它實際上就是PHP源代碼的補丁，旨在將FastCGI進程管理引進到PHP軟體包中，我們必須將其patch到PHP源代碼中，然後再行編譯才能使用。而現在我們可以在PHP 5.3.2及更新版本中直接開啟並使用即可，因為PHP從該版本已經將其收入到軟體包中，所以其不再是補丁包的存在了。

J. PHP進程管理三種模式

ondemand：按請示創建進程數；

dynamic:初始化啟動number進程數；

static：固定啟動進程數；

php-fpm進程管理一共有三種模式： ondemand、static、dynamic ，我們可以在同一個fpm的master配置三種模式，看下圖1。php-fpm的工作模式和nginx類似，都是一個master，多個worker模型。每個worker都在accept本pool內的監聽套接字（linux已不存在驚群現象）。

ondemand

在php-fpm啟動的時候，不會給這個pool啟動任何一個worker，是按需啟動，當有連接過來才會啟動。

配置文件（我的配置文件地址為：/usr/local/php/etc/php-fpm.conf）

當前pool的名字為test

原理

 ondemand原理圖

1. 從上圖可以看出，新建worker的觸發條件是連接的到來，而不是實際的請求（例如，只進行連接比如telnet，不發請求數據也會新建worker）

2. worker的數量受限於pm.max_children配置，同時受限全局配置process.max（准確的說，三種模式都受限於全局配置）

3.1秒定時器作用

找到空閑worker，如果空閑時間超過pm.process_idle_timeout大小，關閉。這個機制可能會關閉所有的worker。

配置項要求

1. pm.max_children> 0

2. pm.process_idle_timeout> 0，如果不設置，默認10s

優缺點

優點：按流量需求創建，不浪費系統資源（在硬體如此便宜的時代，這個優點略顯雞肋）

缺點：由於php-fpm是短連接的，所以每次請求都會先建立連接，建立連接的過程必然會觸發上圖的執行步驟，所以，在大流量的系統上master進程會變得繁忙，佔用系統cpu資源，不適合大流量環境的部署

dynamic

在php-fpm啟動時，會初始啟動一些worker，在運行過程中動態調整worker數量，worker的數量受限於pm.max_children配置，同時受限全局配置process.max

當前pool的名字為test

原理

dynamic原理圖

1. 1秒定時器作用

檢查空閑worker數量，按照一定策略動態調整worker數量，增加或減少。增加時，worker最大數量<=max_children· <=全局process.max；減少時，只有idle >pm.max_spare_servers時才會關閉一個空閑worker。

idle > pm.max_spare_servers，關閉啟動時間最長的一個worker，結束本次處理

idle >= pm.max_children，列印WARNING日誌，結束本次處理

idle < pm.max_children，計算一個num值，然後啟動num個worker，結束本次處理

配置項要求

1. pm.min_spare_servers/pm.max_spare_servers有效范圍(0,pm.max_children]

2. pm.max_children> 0

3. pm.min_spare_servers<=pm.max_spare_servers

4. pm.start_servers有效范圍[pm.min_spare_servers,pm.max_spare_servers]如果沒有配置，默認pm.min_spare_servers + (pm.max_spare_servers - pm.min_spare_servers) / 2

優缺點

優點：動態擴容，不浪費系統資源，master進程設置的1秒定時器對系統的影響忽略不計；

缺點：如果所有worker都在工作，新的請求到來只能等待master在1秒定時器內再新建一個worker，這時可能最長等待1s；

static

php-fpm啟動採用固定大小數量的worker， 在運行期間也不會擴容，雖然也有1秒的定時器，僅限於統計一些狀態信息，例如空閑worker個數，活動worker個數，網路連接隊列長度等信息。

當前pool的名字為test

原理

配置項要求

1、pm.max_children> 0 必須配置，且只有這一個參數生效

優缺點

如果配置成static，只需要考慮max_children的數量，數量取決於cpu的個數和應用的響應時間，我司配置的是50。

我司不考慮動態的增加減少那麼十幾個或者幾十個worker，我們的內存沒有緊張到這個程度，所以，我們一步到位，把worker數配置到支持最大流量，（哈哈，50也是隨便定的，足矣足矣呢）

最後我們再介紹下worker的工作流程

fastcgi與php-fpm的關系一句話解讀：fastcgi只是通信應用協議，php-fpm就是實現了fastcig協議，並嵌入了一個 PHP 解釋器。