php-frm进程管理,PHP内核探索-进程管理

进程管理方式

首先我们了解一下php的三种不同的进程管理方式:

static:静态管理进程。在启动时,master按照pm.max_children配置fork出对应数量的work进程,即work的进程是固定不变的。

dynamic:动态管理进程。在fpm启动时先按照pm.start_servers初始化一定数量的work进程,运行期间如果master发现空闲work进程低于pm.min_spare_servers配置数(表示请求比较多,work处理不过来)时就会主动fork work进程,但是总的work数不能超过pm.max_children,然后如果发现空闲的work数超过了pm.max_spare_servers配置数(表示空闲的work比较多),master则会杀掉一些work进程,避免占用过多资源。

ondemand:这种方式一般很少用,在启动时不分配worker进程,等到有请求了后再通知master进程fork worker进程,总的worker数不超过pm.max_children,处理完成后worker进程不会立即退出,当空闲时间超过pm.process_idle_timeout后再退出

下面我们看下fpm在执行完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]可读事件。

1460000021350449

这个事件是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(),具体逻辑这里不再展开,比较容易理解。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值