Fpmの起動メカニズムとプロセスの詳細な分析（コード付き）

この記事は、Fpm の起動メカニズムとプロセス (コード付き) の詳細な分析を提供します。一定の参考価値があります。必要な友人は参照できます。お役に立てれば幸いです。

FPM (FastCGI Process Manager) は、PHP FastCGI オペレーティング モードのプロセス マネージャーです。その定義から、FPM の中核機能はプロセス管理であることがわかります。では、どのようなプロセスを管理するために使用されるのでしょうか?この問題は FastCGI から始める必要があります。

FastCGI は、Web サーバー (Nginx、Apache など) とハンドラー間の通信プロトコルです。Http に似たアプリケーション層の通信プロトコルです。注: これは単なるプロトコルです。

以前に繰り返し強調したように、PHP は単なるスクリプト パーサーであり、通常の関数として理解でき、入力は PHP スクリプトです。出力は実行結果です。シェルの代わりに PHP を使用してコマンド ラインでファイルを実行したい場合は、PHP パーサーを組み込むプログラムを作成できます。これが cli モードです。このモードでは、PHP は次のようになります。普通のコマンドツール。そこで私たちは、PHP に http リクエストを処理させることができるだろうかと考えました。これにはネットワーク処理が関係し、PHP はリクエストを受信し、プロトコルを解析して、リクエストを処理して返す必要があります。ネットワーク アプリケーションのシナリオでは、PHP は Golang のような http ネットワーク ライブラリを実装しません。代わりに、FastCGI プロトコルを実装し、Web サーバーと連携して http 処理を実装します。Web サーバーは http リクエストを処理し、解析された結果を渡します。 FastCGI を介してプロトコルがハンドラーに転送され、ハンドラーが処理を完了すると結果が Web サーバーに返され、Web サーバーは次の図に示すように結果をユーザーに返します。

PHP は FastCGI プロトコルの分析を実装しますが、特にネットワーク処理を実装しません。一般的な処理モデルは次のとおりです: マルチプロセス、マルチスレッド。マルチプロセス モデルは通常、メイン プロセスのみを意味します。子プロセスの管理を担当し、基本的なネットワーク イベントは nginx や fpm などの各サブプロセスによって処理されます。別のマルチスレッド モデルは、スレッドが細分化されていることを除いて、マルチプロセスに似ています。メイン スレッドは通常、監視とMemcached はリクエストを受信し、処理のためにサブスレッドに渡します。このモードの一部ではマルチプロセス モードも採用されています: メインスレッドはサブスレッドの管理のみを担当し、ネットワーク イベントは処理しません。 -thread リクエストをリッスン、受信、および処理します。Memcached は、UDP プロトコルを使用するときにこのモードを使用します。

1.3.2 基本的な実装
要約すると、fpm の実装は、マスター プロセスを作成し、マスター プロセス内でソケットを作成および監視し、次に複数のサブプロセスをフォークアウトし、これらのそれぞれをフォークすることです。サブプロセスはリクエストを受け付けます サブプロセスの処理は非常に単純です 起動後受け付けでブロックします リクエストが到着するとリクエストデータの読み込みを開始します 読み込み完了後処理を開始してリターンしますこの期間は、他のリクエストを受信しません。つまり、fpm のサブプロセスは、一度に 1 つのリクエストのみに応答できます。次のリクエストは、リクエストが処理された後にのみ受け入れられます。これは、イベントとは大きく異なります。 -driven nginx. nginx のサブプロセスは、epoll を通じてソケットを管理します. リクエスト データが送信されていない場合、次のリクエストが処理されます、つまり、プロセスは複数のリクエストを同時に接続します。ノンブロッキング モデルであり、アクティブなソケットのみを処理します。

fpm マスター プロセスとワーカー プロセスの間には直接通信はありません。マスターは、ワーカー プロセスの現在のステータス、処理されたリクエストの数、マスタープロセスがワーカープロセスを強制終了したい場合など。 ワーカープロセスが使用中の場合、シグナルを送信することでワーカープロセスに通知されます。

fpm は複数のポートを同時に監視でき、nginx のサーバーの概念と同様に、各ポートがワーカー プールに対応し、各プールが複数のワーカー プロセスに対応します。

php-fpm.conf の [プール名] を通じてワーカー プールを宣言します:

[web1]
listen = 127.0.0.1:9000
...

[web2]
listen = 127.0.0.1:9001
...
fpm 起動後のプロセスを確認します: ps -aux|grep fpm

root 27155 0.0 0.1 144704 2720 ? Ss 15:16 0:00 php-fpm: マスタープロセス (/usr/local/php7/etc/php-fpm.conf)
nobody 27156 0.0 0.1 144676 2416 ? S 15:16 0:00 php-fpm : プール web1
誰も 27157 0.0 0.1 144676 2416 ? S 15:16 0:00 php-fpm: プール web1
誰も 27159 0.0 0.1 144680 2376 ? S 15:16 0:00 php-fpm: プール web2
nobody 27160 0.0 0.1 144680 2376 ? S 15:16 0:00 php-fpm: pool web2
特定の実装では、ワーカー プールは fpm_worker_pool_s 構造体で表されます。複数のワーカー プールは単一リンク リストを形成します:

struct fpm_worker_pool_s {
struct fpm_worker_pool_s next; //指向下一个worker pool
struct fpm_worker_pool_config_s config; //conf配置:pm、max_children、start_servers...
int listening_socket; //监听的套接字
...
//以下这个值用于master定时检查、记录worker数
struct fpm_child_s *children; //当前pool的worker链表
int running_children; //当前pool的worker运行总数
int idle_spawn_rate;
int warn_max_children;

struct fpm_scoreboard_s *scoreboard; //记录worker的运行信息，比如空闲、忙碌worker数
...
}

1.3.3 FPM の初期化
main() 関数から始めて、fpm の起動プロセスを見てみましょう:

//sapi/fpm/fpm/fpm_main.c
int main(int argc, char *argv[])
{
...
//注册SAPI:将全局变量sapi_module设置为cgi_sapi_module
sapi_startup(&cgi_sapi_module);
...
//执行php_module_starup()
if (cgi_sapi_module.startup(&cgi_sapi_module) == FAILURE) {
return FPM_EXIT_SOFTWARE;
}
...
//初始化
if(0 > fpm_init(...)){
...
}
...
fpm_is_running = 1;
fcgi_fd = fpm_run(&max_requests);//后面都是worker进程的操作，master进程不会走到下面
parent = 0;
...
}

fpm_init() には主に次の主要な操作があります。

(1)fpm_conf_init_main():

php-fpm.conf 構成ファイルを解析し、ワーカー プールのメモリ構造を割り当て、グローバル変数 fpm_worker_all_pools に保存します。各ワーカー プールの構成はfpm_worker_pool_s->config に解析されます。

(2)fpm​​_scoreboard_init_main(): ワーカー プロセスの実行情報を記録するための共有メモリを割り当てます。これは、ワーカー プール内のワーカー プロセスの最大数に応じて割り当てられます。各ワーカー プールには、fpm_scoreboard_s 構造体が割り当てられます。それぞれに対応します。プール配下のファイル ワーカープロセスは fpm_scoreboard_proc_s 構造体を割り当てます 各構造体の対応関係は以下の通りです。

(3)fpm_signals_init_main():

static int sp[2];
int fpm_signals_init_main()
{
struct sigaction act;
//创建一个全双工管道
if (0 > socketpair(AF_UNIX, SOCK_STREAM, 0, sp)) {
    return -1;
}
//注册信号处理handler
act.sa_handler = sig_handler;
sigfillset(&act.sa_mask);
if (0 > sigaction(SIGTERM,  &act, 0) ||
    0 > sigaction(SIGINT,   &act, 0) ||
    0 > sigaction(SIGUSR1,  &act, 0) ||
    0 > sigaction(SIGUSR2,  &act, 0) ||
    0 > sigaction(SIGCHLD,  &act, 0) ||
    0 > sigaction(SIGQUIT,  &act, 0)) {
    return -1;
}
return 0;
}

这里会通过socketpair()创建一个管道，这个管道并不是用于master与worker进程通信的，它只在master进程中使用，具体用途在稍后介绍event事件处理时再作说明。另外设置master的信号处理handler，当master收到SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT这些信号时将调用sig_handler()处理：

static void sig_handler(int signo)
{
static const char sig_chars[NSIG + 1] = {
[SIGTERM] = 'T',
[SIGINT] = 'I',
[SIGUSR1] = '1',
[SIGUSR2] = '2',
[SIGQUIT] = 'Q',
[SIGCHLD] = 'C'
};
char s;
...
s = sig_chars[signo];
//将信号通知写入管道sp[1]端
write(sp[1], &s, sizeof(s));
...
}

(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进程的。

int fpm_run(int max_requests)
{
struct fpm_worker_pool_s wp;
for (wp = fpm_worker_all_pools; wp; wp = wp->next) {
//调用fpm_children_make() fork子进程
is_parent = fpm_children_create_initial(wp);
   if (!is_parent) {
        goto run_child;
    }
}
//master进程将进入event循环，不再往下走
fpm_event_loop(0);
run_child: //只有worker进程会到这里
*max_requests = fpm_globals.max_requests;
return fpm_globals.listening_socket; //返回监听的套接字
}

在fork后worker进程返回了监听的套接字继续main()后面的处理，而master将永远阻塞在fpm_event_loop()，接下来分别介绍master、worker进程的后续操作。

1.3.4 请求处理
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个阶段：

FPM_REQUEST_ACCEPTING: 等待请求阶段
FPM_REQUEST_READING_HEADERS: 读取fastcgi请求header阶段
FPM_REQUEST_INFO: 获取请求信息阶段，此阶段是将请求的method、query stirng、request uri等信息保存到各worker进程的fpm_scoreboard_proc_s结构中，此操作需要加锁，因为master进程也会操作此结构
FPM_REQUEST_EXECUTING: 执行请求阶段
FPM_REQUEST_END: 没有使用
FPM_REQUEST_FINISHED: 请求处理完成
worker处理到各个阶段时将会把当前阶段更新到fpm_scoreboard_proc_s->request_stage，master进程正是通过这个标识判断worker进程是否空闲的。

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()：

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数量的控制，处理逻辑如下：

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の起動メカニズムとプロセスの詳細な分析（コード付き）の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。