本文目录一览：

1、php-fpm的工作机制
2、如何修改 php-fpm的运行用户
3、服务器程序源代码分析之二：php-fpm
4、php-fpm子进程会自动重启吗
5、如何查看php-fpm core dump 文件的错误

php-fpm的工作机制

概括来说，fpm 的实现就是创建一个 master 进程，在 master 进程中创建并监听 socket，然后 fork 出多个子进程，这些子进程各自 accept 请求，子进程的处理非常简单，它在启动后阻塞在 accept 上，有请求到达后开始读取请求数据，读取完成后开始处理然后再返回，在这期间是不会接收其它请求的，也就是说 fpm 的子进程同时只能响应一个请求，只有把这个请求处理完成后才会 accept 下一个请求，这一点与 nginx 的事件驱动有很大的区别，nginx 的子进程通过 epoll 管理套接字，如果一个请求数据还未发送完成则会处理下一个请求，即一个进程会同时连接多个请求，它是非阻塞的模型，只处理活跃的套接字。 fpm 的 master 进程与 worker 进程之间不会直接进行通信，master 通过共享内存获取 worker 进程的信息，比如 worker 进程当前状态、已处理请求数等，当 master 进程要杀掉一个 worker 进程时则通过发送信号的方式通知 worker 进程。 fpm 可以同时监听多个端口，每个端口对应一个 worker pool，而每个 pool 下对应多个 worker 进程，类似 nginx 中 server 概念。在 `php-fpm.conf` 中通过 `[pool name]` 声明一个 worker pool：启动 fpm 后查看进程：具体实现上 worker pool 通过 `fpm_worker_pool_s` 这个结构表示，多个 worker pool 组成一个单链表。接下来看下 fpm 的启动流程，从 `main()` 函数开始： `fpm_init()` 主要有以下几个关键操作： (1) `fpm_conf_init_main()`: 解析 `php-fpm.conf` 配置文件，分配 worker pool 内存结构并保存到全局变量中：`fpm_worker_all_pools`，各 worker pool 配置解析到 `fpm_worker_pool_s-config` 中。 (2) `fpm_scoreboard_init_main()`: 分配用于记录 worker 进程运行信息的共享内存，按照 worker pool 的最大 worker 进程数分配，每个 worker pool 分配一个 `fpm_scoreboard_s` 结构，pool 下对应的每个 worker 进程分配一个 `fpm_scoreboard_proc_s` 结构。 (3) `fpm_signals_init_main()`: 这里会通过 `socketpair()` 创建一个管道，这个管道并不是用于 master 与 worker 进程通信的，它只在 master 进程中使用，具体用途在稍后介绍 event 事件处理时再作说明。另外设置 master 的信号处理 handler，当 master 收到 `SIGTERM`、`SIGINT`、`SIGUSR1`、`SIGUSR2`、`SIGCHLD`、`SIGQUIT` 这些信号时将调用 `sig_handler()` 处理： (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 进程的。在 fork 后 worker 进程返回了监听的套接字继续 `main()` 后面的处理，而 master 将永远阻塞在 `fpm_event_loop()`，接下来分别介绍 master、worker 进程的后续操作。 `fpm_run()` 执行后将 fork 出 worker 进程，worker 进程返回 `main()` 中继续向下执行，后面的流程就是 worker 进程不断 accept 请求，然后执行 PHP 脚本并返回。整体流程如下： worker 进程一次请求的处理被划分为 5 个阶段： worker 处理到各个阶段时将会把当前阶段更新到 `fpm_scoreboard_proc_s->request_stage`，master 进程正是通过这个标识判断 worker 进程是否空闲的。接下来我们来看下 master 是如何管理 worker 进程的，首先介绍下三种不同的进程管理方式：前面介绍到在 `fpm_run()` 中 master 进程将进入 `fpm_event_loop()`：这就是 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 注册的信号逐个看下不同用途：具体处理逻辑在 `fpm_got_signal()` 函数中，这里不再罗列。 (2) `fpm_pctl_perform_idle_server_maintenance_heartbeat()`: 这是进程管理实现的主要事件，master 启动了一个定时器，每隔 1s 触发一次，主要用于 dynamic、ondemand 模式下的 worker 管理，master 会定时检查各 worker pool 的 worker 进程数，通过此定时器实现 worker 数量的控制，处理逻辑如下： (3) `fpm_pctl_heartbeat()`: 这个事件是用于限制 worker 处理单个请求最大耗时的，`php-fpm.conf` 中有一个 `request_terminate_timeout` 的配置项，如果 worker 处理一个请求的总时长超过了这个值那么 master 将会向此 worker 进程发送 `kill -TERM` 信号杀掉 worker 进程，此配置单位为秒，默认值为 0 表示关闭此机制，另外 fpm 打印的 slow log 也是在这里完成的。除了上面这几个事件外还有一个没有提到，那就是 ondemand 模式下 master 监听的新请求到达的事件，因为 ondemand 模式下 fpm 启动时是不会预创建 worker 的，有请求时才会生成子进程，所以请求到达时需要通知 master 进程，这个事件是在 `fpm_children_create_initial()` 时注册的，事件处理函数为 `fpm_pctl_on_socket_accept()`，具体逻辑这里不再展开，比较容易理解。原文出处：

如何修改 php-fpm的运行用户

第一种：一个php-fpm主进程

这种方式比较简单，也只需要一个php-fpm自启动文件。首先我们查看一下原 php-fpm.conf 的这个配置文件，分为两个部分，一个是 global 块，另外一个是自定义的块，配置文件里面称为 pool 池，默认叫“www”。在 global 池的上方，有一行注释了的 include=etc/fpm.d/*.conf 配置项，再通过 www 池的配置，我们可知可以通过不同的池来配置不同的用户，来达到多个用户运行 php-fpm 的目的，步骤如下： 4、删除前面的 global 块，或者注释掉。 5、修改 [www] 为其他，比如你 [blog]。 6、配置 [blog] 池，主要修改两个地方: 6.1：第一处为运行的用户和用户组。即将

user = www
group = www

修改为

user = nobody #具体用哪个用户视自己情况而定，我只做个示例
group = nobody

6.2：修改监听的端口或者 socket：即将：

listen = 127.0.0.1:9000

修改为：

listen = /var/socket/php-fpm/blog.socket #php-fpm需要自己创建，当然也可以直接放在php-fpm目录下

修改成其他端口也是可以的，比如：listen = 127.0.0.1:9001。 7、到主配置文件 php-fpm.conf 将 include=… 前面的注释去掉，让它去读取 fpm.d 目录下的配置文件。 8、到此第一种方案就修改完毕了，重新启动测试一下：

service php-fpm reload

第二种：两个php-fpm主进程

这种方法需要独立的配置文件和独立的自启动文件： 1、复制一份 php-fpm.conf 主配置文件。

cp php-fpm.conf php-fpm-blog.conf

2、修改主配置文件。

vim php-fpm-blog.conf

2.1：修改 [global] 下 pid 和 error_log 文件的路径。修改 pid=run/php-fpm.pid 为 pid=run/php-fpm-blog.pid。修改 error_log = /log/php-fpm.log 为 error_log = /log/php-fpm-blog.log。 2.2：修改池的名称 [www] 为 [blog]，不过这个可以不用修改了，因为这里和原来的进程是独立的。 2.3：修改用户和用户组。 2.4：监听端口或 socket 文件。以上两部可以按照第一种方案进行修改，这里就不再重复。 3、进入 /etc/init.d 目录，复制一份自启动文件。

cp php-fpm php-fpm2

4、修改自启动文件 php-fpm2： 4.1：修改配置文件路径。

php_fpm_CONF=${prefix}/etc/php-fpm.conf

为

php_fpm_CONF=${prefix}/etc/php-fpm-blog.conf

这个路径就是刚才的主配置文件。 4.2：修改 PID 文件路径：

php_fpm_PID=${prefix}/var/run/php-fpm.pid

为：

php_fpm_PID=${prefix}/var/run/php-fpm-blog.pid

这个路径要和主配置文件中的 pid 路径一致。 5、修改完毕后添加自动启动。

chkconfig --add php-fpm2
chkconfig --level 2345 php-fpm2 on

6、启动服务。

服务器程序源代码分析之二：php-fpm

php 作为排名 top2 互联网开发工具，非常流行，可以参考：中国最大的 25 个网站采用技术选型方案 php 这个名称实际上有两层含义直接定义： php-fpm 从 php5.3.3 开始已经进入到 php 源代码包，之前是作为 patch 存在的很少人会去读 php 本身源代码，我 6 年前解决 php 内存泄露问题的时候做了些研究,最近再查看了一番，发现 php 的开发者很有诚意，这是一款非常出色的服务器软件，支持如下在 linux 服务器上，如果不设置 `events.mechanism`，那么默认就是采用 epoll，所以 php-fpm 的 IO 模型并发处理能力和 nginx 是完全一致 nginx 以性能卓越闻名，大部分程序员都认为 php 效率低下，看了源代码，才知道这是传奇啊在高性能部署的时候，大家往往会针对性的优化 nginx。我自己之前部署 php 程序也犯了错误，8G 内存的 server，php-fpm 的 max children 都会设置 128+，现在看来太多了，参考 nginx 的部署: php-fpm 配置为 3 倍 cpu core number 就可以了 php-fpm 稳定性比 nginx 稍差这是因为 php-fpm 内置了一个 php 解析器,php-fpm 进程就和 php 程序捆绑了，如果 php 脚本写得不好，有死循环或者阻塞在某个远端资源上，会拖累加载它的 php-fpm 进程而 nginx 和后端应用服务器之间通过网络连接，可以设置 timeout，不容易堵死的 php-fpm 的 fastcgi 是短连接我原以为是长连接的，看了代码才知道也是短连接，处理一个 request 就关闭掉 php-fpm 接口采用 fastcgi 非常遗憾，php-fpm 和 fastcgi 完全绑定了，无法独立使用。只能部署在支持 http-fcgi 协议转换程序背后 (nginx）。其实可以考虑在 php-fpm 代码包里面引入 http 协议支持，这样 php-fpm 可以独立运行，让 nodejs 无话可说 php-fpm 等同于 OpenResty OpenResty 是一个国人开发的 nginx 模块，就是在 nginx 引入 lua 解释器。实际上，它和 php-fpm 的唯一差别就是一个采用 php 语法，一个用 lua，所以 OpenResty 要作为 nginx 增强包使用还可以，要选择它作为一个主要编程工具，没有任何必要从架构上来说，php-fpm 已经做到最好，超过大多数 python 部署工具，我再也不黑它了

php-fpm子进程会自动重启吗

服务器出现异常，网站不能正常访问。经排查 php 的问题。在重启 php-fpm 时，恢复正常。1 分钟之后又出现故障。查看 php 日志文件 /usr/local/php/var/log 后提示

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

子进程数已经达到设置的最大值。要设置 php 进程数量。需要在 php-fpm.conf 文件中修改。先看 /usr/local/php/etc/php-fpm.conf 文件各项配置解析

pid = run/php-fpm.pid
#pid设置，默认在安装目录中的var/run/php-fpm.pid，建议开启
error_log = log/php-fpm.log
#错误日志，默认在安装目录中的var/log/php-fpm.log
log_level = notice
#错误级别. 可用级别为: alert（必须立即处理）, error（错误情况）, warning（警告情况）, notice（一般重要信息）, debug（调试信息）. 默认: notice.
emergency_restart_threshold = 60
emergency_restart_interval = 60s
#表示在emergency_restart_interval所设值内出现SIGSEGV或者SIGBUS错误的php-cgi进程数如果超过 emergency_restart_threshold个，php-fpm就会优雅重启。这两个选项一般保持默认值。
process_control_timeout = 0
#设置子进程接受主进程复用信号的超时时间. 可用单位: s(秒), m(分), h(小时), 或者 d(天) 默认单位: s(秒). 默认值: 0.
daemonize = yes
#后台执行fpm,默认值为yes，如果为了调试可以改为no。在FPM中，可以使用不同的设置来运行多个进程池。 这些设置可以针对每个进程池单独设置。
listen = 127.0.0.1:9000
#fpm监听端口，即nginx中php处理的地址，一般默认值即可。可用格式为: ‘ip:port’, ‘port’, ‘/path/to/unix/socket’. 每个进程池都需要设置.
listen.backlog = -1
#backlog数，-1表示无限制，由操作系统决定，此行注释掉就行。backlog含义参考：
listen.allowed_clients = 127.0.0.1
#允许访问FastCGI进程的IP，设置any为不限制IP，如果要设置其他主机的nginx也能访问这台FPM进程，listen处要设置成本地可被访问的IP。默认值是any。每个地址是用逗号分隔. 如果没有设置或者为空，则允许任何服务器请求连接
listen.owner = www
listen.group = www
listen.mode = 0666
#unix socket设置选项，如果使用tcp方式访问，这里注释即可。
user = www
group = www
#启动进程的帐户和组
pm = dynamic #对于专用服务器，pm可以设置为static。
#如何控制子进程，选项有static和dynamic。如果选择static，则由pm.max_children指定固定的子进程数。如果选择dynamic，则由下开参数决定：
pm.max_children #，子进程最大数
pm.start_servers #，启动时的进程数
pm.min_spare_servers #，保证空闲进程数最小值，如果空闲进程小于此值，则创建新的子进程
pm.max_spare_servers #，保证空闲进程数最大值，如果空闲进程大于此值，此进行清理
pm.max_requests = 1000
#设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为 ’0′ 则一直接受请求. 等同于 PHP_FCGI_MAX_REQUESTS 环境变量. 默认值: 0.
pm.status_path = /status
#FPM状态页面的网址. 如果没有设置, 则无法访问状态页面. 默认值: none. munin监控会使用到
ping.path = /ping
#FPM监控页面的ping网址. 如果没有设置, 则无法访问ping页面. 该页面用于外部检测FPM是否存活并且可以响应请求. 请注意必须以斜线开头 (/)。
ping.response = pong
#用于定义ping请求的返回相应. 返回为 HTTP 200 的 text/plain 格式文本. 默认值: pong.
request_terminate_timeout = 0
#设置单个请求的超时中止时间. 该选项可能会对php.ini设置中的’max_execution_time’因为某些特殊原因没有中止运行的脚本有用. 设置为 ’0′ 表示 ‘Off’.当经常出现502错误时可以尝试更改此选项。
request_slowlog_timeout = 10s
#当一个请求该设置的超时时间后，就会将对应的PHP调用堆栈信息完整写入到慢日志中. 设置为 ’0′ 表示 ‘Off’
slowlog = log/$pool.log.slow
#慢请求的记录日志,配合request_slowlog_timeout使用
rlimit_files = 1024
#设置文件打开描述符的rlimit限制. 默认值: 系统定义值默认可打开句柄是1024，可使用 ulimit -n查看，ulimit -n 2048修改。
rlimit_core = 0
#设置核心rlimit最大限制值. 可用值: ‘unlimited’ 、0或者正整数. 默认值: 系统定义值.
chroot =
#启动时的Chroot目录. 所定义的目录需要是绝对路径. 如果没有设置, 则chroot不被使用.
chdir =
#设置启动目录，启动时会自动Chdir到该目录. 所定义的目录需要是绝对路径. 默认值: 当前目录，或者/目录（chroot时）
catch_workers_output = yes
#重定向运行过程中的stdout和stderr到主要的错误日志文件中. 如果没有设置, stdout 和 stderr 将会根据FastCGI的规则被重定向到 /dev/null . 默认值: 空.

根据以上配置的解析，在 php-fpm.conf 文件中添加如下配置:

pm.max_children = 100
pm.start_servers = 30
pm.min_spare_servers = 20
pm.max_spare_servers = 100

以观后效。另附豆瓣技术贴: 1、php-fpm优化参数介绍他们分别是：pm、pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers。 pm：表示使用那种方式，有两个值可以选择，就是 static（静态）或者 dynamic（动态）。在更老一些的版本中，dynamic 被称作 apache-like。这个要注意看配置文件的说明。下面 4 个参数的意思分别为： pm.max_children：静态方式下开启的 php-fpm 进程数量
pm.start_servers：动态方式下的起始 php-fpm 进程数量
pm.min_spare_servers：动态方式下的最小 php-fpm 进程数
pm.max_spare_servers：动态方式下的最大 php-fpm 进程数量
区别：如果 pm 设置为 static，那么其实只有 pm.max_children 这个参数生效。系统会开启设置数量的 php-fpm 进程。如果 pm 设置为 dynamic，那么 pm.max_children 参数失效，后面 3 个参数生效。系统会在 php-fpm 运行开始的时候启动 pm.start_servers 个 php-fpm 进程，然后根据系统的需求动态在 pm.min_spare_servers 和 pm.max_spare_servers 之间调整 php-fpm 进程数 2、服务器具体配置对于我们的服务器，选择哪种执行方式比较好呢？事实上，跟 Apache 一样，运行的 PHP 程序在执行完成后，或多或少会有内存泄露的问题。这也是为什么开始的时候一个 php-fpm 进程只占用 3M 左右内存，运行一段时间后就会上升到 20-30M 的原因了。对于内存大的服务器（比如 8G 以上）来说，指定静态的 max_children 实际上更为妥当，因为这样不需要进行额外的进程数目控制，会提高效率。因为频繁开关 php-fpm 进程也会有时滞，所以内存够大的情况下开静态效果会更好。数量也可以根据内存/30M 得到，比如 8GB 内存可以设置为 100，那么 php-fpm 耗费的内存就能控制在 2G-3G 的样子。如果内存稍微小点，比如 1G，那么指定静态的进程数量更加有利于服务器的稳定。这样可以保证 php-fpm 只获取够用的内存，将不多的内存分配给其他应用去使用，会使系统的运行更加畅通。对于小内存的服务器来说，比如 256M 内存的 VPS，即使按照一个 20M 的内存量来算，10 个 php-cgi 进程就将耗掉 200M 内存，那系统的崩溃就应该很正常了。因此应该尽量地控制 php-fpm 进程的数量，大体明确其他应用占用的内存后，给它指定一个静态的小数量，会让系统更加平稳一些。或者使用动态方式，因为动态方式会结束掉多余的进程，可以回收释放一些内存，所以推荐在内存较少的服务器或 VPS 上使用。具体最大数量根据内存/20M 得到。比如说 512M 的 VPS，建议 pm.max_spare_servers 设置为 20。至于 pm.min_spare_servers，则建议根据服务器的负载情况来设置，比如服务器上只是部署 php 环境的话，比较合适的值在 5~10 之间。

本服务器配置

1、服务器基本信息：硬盘：数据盘 30G、系统盘 20G
内存：1.5G
CPU：双核
系统：CentOS 6.3 64 位
带宽：独享 2M
2、部署的应用 Git、SVN、Apache、Tomcat、PHP、Nginx、mysql、JDK
3、优化后的参数

pm = dynamic
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 8

如何查看php-fpm core dump 文件的错误

后盾网哪里有好多学习资料，什么都有，你可以去哪里找找答案

phpfpmcore的简单介绍