1.3.5 进程管理

### 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的实现还是比较简单的。