### 1.3.5 進程管理 這一節我們來看下master是如何管理worker進程的，首先介紹下三種不同的進程管理方式： * __static:__ 這種方式比較簡單，在啟動時master按照`pm.max_children`配置fork出相應數量的worker進程，即worker進程數是固定不變的 * __dynamic:__ 動態進程管理，首先在fpm啟動時按照`pm.start_servers`初始化一定數量的worker，運行期間如果master發現空閑worker數低于`pm.min_spare_servers`配置數(表示請求比較多，worker處理不過來了)則會fork worker進程，但總的worker數不能超過`pm.max_children`，如果master發現空閑worker數超過了`pm.max_spare_servers`(表示閑著的worker太多了)則會殺掉一些worker，避免占用過多資源，master通過這4個值來控制worker數 * __ondemand:__ 這種方式一般很少用，在啟動時不分配worker進程，等到有請求了后再通知master進程fork worker進程，總的worker數不超過`pm.max_children`，處理完成后worker進程不會立即退出，當空閑時間超過`pm.process_idle_timeout`后再退出 前面介紹到在`fpm_run()`master進程將進入`fpm_event_loop()`： ```c void fpm_event_loop(int err) { //創建一個io read的監聽事件，這里監聽的就是在fpm_init()階段中通過socketpair()創建管道sp[0] //當sp[0]可讀時將回調fpm_got_signal() fpm_event_set(&signal_fd_event, fpm_signals_get_fd(), FPM_EV_READ, &fpm_got_signal, NULL); fpm_event_add(&signal_fd_event, 0); //如果在php-fpm.conf配置了request_terminate_timeout則啟動心跳檢查 if (fpm_globals.heartbeat > 0) { fpm_pctl_heartbeat(NULL, 0, NULL); } //定時觸發進程管理 fpm_pctl_perform_idle_server_maintenance_heartbeat(NULL, 0, NULL); //進入事件循環，master進程將阻塞在此 while (1) { ... //等待IO事件 ret = module->wait(fpm_event_queue_fd, timeout); ... //檢查定時器事件 ... } } ``` 這就是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注冊的信號逐個看下不同用途： * __SIGINT/SIGTERM/SIGQUIT:__ 退出fpm，在master收到退出信號后將向所有的worker進程發送退出信號，然后master退出 * __SIGUSR1:__ 重新加載日志文件，生產環境中通常會對日志進行切割，切割后會生成一個新的日志文件，如果fpm不重新加載將無法繼續寫入日志，這個時候就需要向master發送一個USR1的信號 * __SIGUSR2:__ 重啟fpm，首先master也是會向所有的worker進程發送退出信號，然后master會調用execvp()重新啟動fpm，最后舊的master退出 * __SIGCHLD:__ 這個信號是子進程退出時操作系統發送給父進程的，子進程退出時，內核將子進程置為僵尸狀態，這個進程稱為僵尸進程，它只保留最小的一些內核數據結構，以便父進程查詢子進程的退出狀態，只有當父進程調用wait或者waitpid函數查詢子進程退出狀態后子進程才告終止，fpm中當worker進程因為異常原因(比如coredump了)退出而非master主動殺掉時master將受到此信號，這個時候父進程將調用waitpid()查下子進程的退出，然后檢查下是不是需要重新fork新的worker 具體處理邏輯在`fpm_got_signal()`函數中，這里不再羅列。 __(2)fpm_pctl_perform_idle_server_maintenance_heartbeat():__ 這是進程管理實現的主要事件，master啟動了一個定時器，每隔1s觸發一次，主要用于dynamic、ondemand模式下的worker管理，master會定時檢查各worker pool的worker進程數，通過此定時器實現worker數量的控制，處理邏輯如下： ```c static void fpm_pctl_perform_idle_server_maintenance(struct timeval *now) { for (wp = fpm_worker_all_pools; wp; wp = wp->next) { struct fpm_child_s *last_idle_child = NULL; //空閑時間最久的worker int idle = 0; //空閑worker數 int active = 0; //忙碌worker數 for (child = wp->children; child; child = child->next) { //根據worker進程的fpm_scoreboard_proc_s->request_stage判斷 if (fpm_request_is_idle(child)) { //找空閑時間最久的worker ... idle++; }else{ active++; } } ... //ondemand模式 if (wp->config->pm == PM_STYLE_ONDEMAND) { if (!last_idle_child) continue; fpm_request_last_activity(last_idle_child, &last); fpm_clock_get(&now); if (last.tv_sec < now.tv_sec - wp->config->pm_process_idle_timeout) { //如果空閑時間最長的worker空閑時間超過了process_idle_timeout則殺掉該worker last_idle_child->idle_kill = 1; fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT); } continue; } //dynamic if (wp->config->pm != PM_STYLE_DYNAMIC) continue; if (idle > wp->config->pm_max_spare_servers && last_idle_child) { //空閑worker太多了，殺掉 last_idle_child->idle_kill = 1; fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT); wp->idle_spawn_rate = 1; continue; } if (idle < wp->config->pm_min_spare_servers) { //空閑worker太少了，如果總worker數未達到max數則fork ... } } } ``` __(3)fpm_pctl_heartbeat():__ 這個事件是用于限制worker處理單個請求最大耗時的，php-fpm.conf中有一個`request_terminate_timeout`的配置項，如果worker處理一個請求的總時長超過了這個值那么master將會向此worker進程發送`kill -TERM`信號殺掉worker進程，此配置單位為秒，默認值為0表示關閉此機制，另外fpm打印的slow log也是在這里完成的。 ```c static void fpm_pctl_check_request_timeout(struct timeval *now) { struct fpm_worker_pool_s *wp; for (wp = fpm_worker_all_pools; wp; wp = wp->next) { int terminate_timeout = wp->config->request_terminate_timeout; int slowlog_timeout = wp->config->request_slowlog_timeout; struct fpm_child_s *child; if (terminate_timeout || slowlog_timeout) { for (child = wp->children; child; child = child->next) { //檢查當前當前worker處理的請求是否超時 fpm_request_check_timed_out(child, now, terminate_timeout, slowlog_timeout); } } } } ``` 除了上面這幾個事件外還有一個沒有提到，那就是ondemand模式下master監聽的新請求到達的事件，因為ondemand模式下fpm啟動時是不會預創建worker的，有請求時才會生成子進程，所以請求到達時需要通知master進程，這個事件是在`fpm_children_create_initial()`時注冊的，事件處理函數為`fpm_pctl_on_socket_accept()`，具體邏輯這里不再展開，比較容易理解。 到目前為止我們已經把fpm的核心實現介紹完了，事實上fpm的實現還是比較簡單的。