深入了解FPM(三)

作者:有用网
请求处理
fpm_run() 执行后将fork出worker进程,worker进程返回 main() 中继续向下执行,后面的流程就是worker进程不断accept请求,然后执行PHP脚本并返回。整体流程如下:
(1)等待请求: worker进程阻塞在fcgi_accept_request()等待请求;
(2)解析请求: fastcgi请求到达后被worker接收,然后开始接收并解析请求数据,直到request数据完全到达;
(3)请求初始化: 执行php_request_startup(),此阶段会调用每个扩展的:PHP_RINIT_FUNCTION();
(4)编译、执行: 由php_execute_script()完成PHP脚本的编译、执行;
(5)关闭请求: 请求完成后执行php_request_shutdown(),此阶段会调用每个扩展的:PHP_RSHUTDOWN_FUNCTION(),然后进入步骤(1)等待下一个请求。
int main(int argc, char *argv[])
{
    ...
    fcgi_fd = fpm_run(&max_requests);
    parent = 0;
    //初始化fastcgi请求
    request = fpm_init_request(fcgi_fd);
    //worker进程将阻塞在这,等待请求
    while (EXPECTED(fcgi_accept_request(request) >= 0)) {
        SG(server_context) = (void *) request;
        init_request_info();
        //请求开始
        if (UNEXPECTED(php_request_startup() == FAILURE)) {
        ...
        }
        ...
        fpm_request_executing();
        //编译、执行PHP脚本
        php_execute_script(&file_handle);
        ...
        //请求结束
        php_request_shutdown((void *) 0);
        ...
    }
    ...
    //worker进程退出
    php_module_shutdown();
    ...
}
worker进程一次请求的处理被划分为5个阶段: 
1. FPM_REQUEST_ACCEPTING: 等待请求阶段
2. __FPM_REQUEST_READING_HEADERS:__ 读取fastcgi请求header阶段
3. FPM_REQUEST_INFO: 获取请求信息阶段,此阶段是将请求的method、query stirng、request uri等信息保存到各worker进程的fpm_scoreboard_proc_s结构中,此操作需要加锁,因为master进程也会操作此结构
4. FPM_REQUEST_EXECUTING: 执行请求阶段
5. FPM_REQUEST_END: 没有使用
6. FPM_REQUEST_FINISHED: 请求处理完成
worker处理到各个阶段时将会把当前阶段更新到fpm_scoreboard_proc_s->request_stage,master进程正是通过这个标识判断worker进程是否空闲的。 

进程管理
我们来看下master是如何管理worker进程的,首先介绍下三种不同的进程管理方式:
1. static: 这种方式比较简单,在启动时master按照 pm.max_children 配置fork出相应数量的worker进程,即worker进程数是固定不变的
2.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数 
3.ondemand: 这种方式一般很少用,在启动时不分配worker进程,等到有请求了后再通知master进程fork worker进程,总的worker数不超过 pm.max_children ,处理完成后worker进程不会立即退出,当空闲时间超过 pm.process_idle_timeout 后再退出 

前面介绍到在 fpm_run() master进程将进入 fpm_event_loop() : 
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, &f
    pm_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注册的信号逐个看下不同用途: 

1. SIGINT/SIGTERM/SIGQUIT: 退出fpm,在master收到退出信号后将向所有的worker进程发送退出信号,然后master退出 

2.SIGUSR1: 重新加载日志文件,生产环境中通常会对日志进行切割,切割后会生成一个新的日志文件,如果fpm不重新加载将无法继续写入日志,这个时候就需要向master发送一个USR1的信号 
3. SIGUSR2: 重启fpm,首先master也是会向所有的worker进程发送退出信号,然后master会调用execvp()重新启动fpm,最后旧的master退出 
4.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数量的控制,处理逻辑如下: 
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也是在这里完成的。 
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的实现还是比较简单的。 

关键字
FPM

阅读 414 发布于 2021-08-18