phpfpmcore的簡單介紹

本文目錄一覽：

• 1、php-fpm的工作機制
• 2、如何修改 php-fpm的運行用戶
• 3、服務器程序源代碼分析之二：php-fpm
• 4、php-fpm子進程會自動重啟嗎
• 5、如何查看php-fpm core dump 文件的錯誤

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()，具體邏輯這裡不再展開，比較容易理解。

原文出處：

如何修改 php-fpm的運行用戶

第一種：一個php-fpm主進程

這種方式比較簡單，也只需要一個php-fpm自啟動文件。

首先我們查看一下原php-fpm.conf的這個配置文件，分為兩個部分，一個是global塊，另外一個是自定義的塊，配置文件裡面稱為pool池，默認叫“www”。在global池的上方，有一行注釋了的“include=etc/fpm.d/*.conf”配置項，再通過www池的配置，我們可知可以通過不同的池來配置不同的用戶，來達到多個用戶運行php-fpm的目的，步驟如下：

4、刪除前面的global塊，或者注釋掉。

5、修改[www]為其他，比如你[blog]。

6、配置[blog]池，主要修改兩個地方:

6.1：第一處為運行的用戶和用戶組。

即將

12user = www3group = www4。

修改為

12user=nobody #具體用哪個用戶視自己情況而定，我只做個示例3group=nobody4。

6.2：修改監聽的端口或者socket：

即將：

12listen = 127.0.0.1:90003。

修改為：

12listen = /var/socket/php-fpm/blog.socket #php-fpm需要自己創建，當然也可以直接放在php-fpm目錄下3。

修改成其他端口也是可以的，比如：listen = 127.0.0.1:9001。

7、到主配置文件 php-fpm.conf將“include=…”前面的注釋去掉，讓它去讀取fpm.d目錄下的配置文件。

8、到此第一種方案就修改完畢了，重新啟動測試一下：

12service php-fpm reload3。

第二種：兩個php-fpm主進程。

這種方法需要獨立的配置文件和獨立的自啟動文件：

1、複製一份php-fpm.conf主配置文件。

12cp php-fpm.conf php-fpm-blog.conf3。

2、修改主配置文件。

12vim php-fpm-blog.conf3。

2.1：修改[global]下pid和error_log文件的路徑。

修改 pid=run/php-fpm.pid 為 pid=run/php-fpm-blog.pid 。

修改 error_log = /log/php-fpm.log 為 error_log = /log/php-fpm-blog.log。

2.2：修改池的名稱[www]為[blog]，不過這個可以不用修改了，因為這裡和原來的進程是獨立的。

2.3：修改用戶和用戶組。

2.4：監聽端口或socket文件。

以上兩部可以按照第一種方案進行修改，這裡就不再重複。

3、進入/etc/init.d目錄，複製一份自啟動文件。

12cp php-fpm php-fpm23。

4、修改自啟動文件php-fpm2：

4.1：修改配置文件路徑。

12php_fpm-CONF=${prefix}/etc/php-fpm.conf3。

為

12php_fpm-CONF=${prefix}/etc/php-fpm-blog.conf3。

這個路徑就是剛才的主配置文件。

4.2：修改PID文件路徑：

12php_fpm_PID=${prefix}/var/run/php-fpm.pid3。

為：

12php_fpm_PID=${prefix}/var/run/php-fpm-blog.pid3。

這個路徑要和主配置文件中的pid路徑一致。

5、修改完畢後添加自動啟動。

12chkconfig –add php-fpm23chkconfig –level 2345 php-fpm2 on4。

6、啟動服務。

服務器程序源代碼分析之二：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部署工具，我再也不黑它了

php-fpm子進程會自動重啟嗎

服務器出現異常，網站不能正常訪問。經排查�php的問題。

在重啟php-fpm時，恢復正常。1分鐘之後又出現故障。查看php日誌文件/usr/local/php/var/log 後提示

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

子進程數已經達到設置的最大值。

要設置php進程數量。需要在php-fpm.conf文件中修改。

先看/usr/local/php/etc/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含義參考：

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 . 默認值: 空.

根據以上配置的解析，在php-fpm.conf文件中添加如下配置:

pm.max_children = 100

pm.start_servers = 30

pm.min_spare_servers = 20

pm.max_spare_servers = 100

以觀後效。

另附豆瓣技術貼:

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

如何查看php-fpm core dump 文件的錯誤

後盾網哪裡有好多學習資料，什麼都有，你可以去哪裡找找答案