本文目錄一覽：
如何用php-fpm 執行php程序
第一步：確定php-fpm配置文件的路徑，執行：
ps -aux | grep php-fpm
圖中，我的是在 /soft/php7/etc/ 目錄，在這個目錄下有個php-fpm.d目錄，打開這個目錄後，找到文件，修改該文件里：
user = www
group = www
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()，具體邏輯這裡不再展開，比較容易理解。
原文出處：
如何用supervisor守護php-fpm主進程以實現php-fpm的自動重啟
1. 安裝supervisor
supervisor本身是python實現的，而且是調研階段，故先創建一個新的virtualenv環境，然後用pip安裝好supervisor包。
至此，基本的調研環境搭建完畢。當然，php-fpm和PHP環境以及前端的Nginx是早就ready的。
2. 分析php-fpm.sh腳本
通常編譯安裝PHP後，php-fpm這個2進位的C程序也會被編譯並安裝好，典型路徑在php_install_path/sbin/目錄下。該
目錄下還有個名為php-fpm.sh的腳本用於控制php-fpm進程的start/stop/restart/reload等動作。
./sbin/php-fpm.sh腳本中，」start」操作啟動了php-fpm主進程，其餘的操作都是通過向php-fpm master進程發signal實現的。
code class=”hljs bash”## code segment in php-fpm.sh
case “$1” in
start)
echo -n “Starting php-fpm “
## 下面這行是關鍵命令
$php_fpm_BIN –daemonize $php_opts
if [ “$?” != 0 ] ; then
echo ” failed”
exit 1
fi
wait_for_pid created $php_fpm_PID
if [ -n “$try” ] ; then
echo ” failed”
exit 1
else
echo ” done”
fi
;;/code
從上面是終端輸入」./sbin/php-fpm.sh
start」時，實際執行的代碼，可以看到，php-fpm進程的啟動參數是–daemonize
$php_opts，而$php_opts的值為」–fpm-config $php_fpm_CONF –pid $php_fpm_PID」。
注意: php-fpm.sh啟動php-fpm master進程時，傳入了daemonize參數，表明php-fpm master process以守護（daemon）方式啟動，而根據supervisor文檔的說明，當用supervisor監護進程時，被監護進程不能是守護進程，這是由於守護進程通常會在fork完子進程後就讓父進程」結束生命」，也即由supervisor創建的父進程退出，此時，supervisor無法再監護已退出進程創建出來的子進程。關於daemon process的行為，可以參考Linux Daemon Writing HOWTO一文來理解。
根據上面的分析，我們知道，只要supervisor啟動php-fpm進程時，不傳入daemonize參數即可。
3. 實現php-fpm主進程守護功能的supervisor配置文件
上面的分析已經告訴我們應該怎麼解決問題了，下面直接上驗證可用的配置文件。文件位於php-fpm.conf同級目錄下（典型路徑為php_install_path/etc/）。
code class=”hljs bash”code class=”hljs vhdl”
[inet_http_server] ; inet (TCP) server disabled by default
port=127.0.0.1:9015 ; (ip_address:port specifier, *:port for all iface)
[supervisord]
logfile=./var/log/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=2 ; (num of main logfile rotation backups;default 10)
loglevel=info ; (log level;default info; others: debug,warn,trace)
pidfile=./var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false ; (start in foreground if true;default false)
minfds=1024 ; (min. avail startup file descriptors;default 1024)
minprocs=200 ; (min. avail process descriptors;default 200)
identifier=sup.php-fpm ; (supervisord identifier, default is ‘supervisor’)
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl= ; use an http:// url to specify an inet socket
[program:php-fpm]
command=bash -c “sleep 1 /home/slvher/tools/php/5.6.11/sbin/php-fpm –fpm-config /home/slvher/tools/php/5.6.11/etc/php-fpm.conf –pid /home/slvher/tools/php/5.6.11/var/run/php-fpm.pid” ; the program (relative uses PATH, can take args)
process_name=%(program_name)s ; process_name expr (default %(program_name)s)
autostart=true ; start at supervisord start (default: true)
autorestart=true ; whether/when to restart (default: unexpected)
startretries=5 ; max # of serial start failures (default 3)
exitcodes=0,2,70 ; ‘expected’ exit codes for process (default 0,2)
stopsignal=QUIT ; signal used to kill process (default TERM)
stopwaitsecs=2 ; max num secs to wait b4 SIGKILL (default 10)
/code/code
配置文件結構通過查看supervisor文檔很容易就能掌握，有兩個配置項需要特別注意：
1) command
它指定了supervisor要監控的進程的啟動命令，可以看到，這裡我們沒有給php-fpm傳入daemonize參數，其餘參數只是展開了php-fpm.sh中的shell變數而已。
大家已經注意到，command也不是直接調起php-fpm，而是通過bash -c執行了兩個命令，而第一個命令是sleep 1。這是由於php-fpm在stop後，其佔用的埠通常不能立即釋放，此時，supervisor以極快的速度試圖重新拉起進程時，可能會由於報如下錯誤而導致幾次retry均失敗：
code class=”hljs bash”code class=”hljs vhdl”code class=”hljs vbscript”## var/log/php-fpm.error.log
[18-Jul-2015 21:35:28] ERROR: unable to bind listening socket for address ‘127.0.0.1:9002’: Address already in use (98)
[18-Jul-2015 21:35:28] ERROR: FPM initialization failed/code/code/code
而supervisor目前還不支持delay restart功能，因此，這裡只能通過先sleep再啟動的略顯tricky的方法來解決問題，結果表明，療效不錯且無副作用。-_-
2) autorestart
其文檔描述如下：
code class=”hljs bash”code class=”hljs vhdl”code class=”hljs vbscript”code class=”hljs livecodeserver”May be one of false, unexpected, or true. If false, the process will never be autorestarted. If unexpected, the process will be restart when the program exits with an exit code that is not one of the exit codes associated with this process』 configuration (see exitcodes). If true, the process will be unconditionally restarted when it exits, without regard to its exit code./code/code/code/code
其默認值是unexpected，表示若被監護進程的exit code異常時，supervisor才會重新拉起進程。這裡設置為true，表明任何時候進程退出均會被再次拉起。
這樣配置好後，在本文第1步搭建好的virtualenv環境中，運行如下命令即可完成supervisor對php-fpm master進程的監護：
code class=”hljs bash”code class=”hljs vhdl”code class=”hljs vbscript”code class=”hljs livecodeserver”code class=”hljs avrasm”shell supervisord -c etc/sup.php-fpm.conf/code/code/code/code/code
然後，通過ps x | fgrep fpm可以看到，php-fpm主進程已經被拉起了。
然後，kill掉php-fpm主進程，再次ps x | fgrep fpm可以看到，一個新的php-fpm主進程會被supervisor創建出來。
至此，用supervisor守護php-fpm主進程以實現php-fpm的自動重啟的需求已經解決了。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/207191.html
微信掃一掃 
支付寶掃一掃 