phpfpm启动
Linux中crontab是实现定时执行的指令，利用这个指令我们就可以定时执行某一个php文件，从而实现用PHP做Linux自动执行脚本。如何用PHP作Linux自动执行脚本？
在安装PHP的时候,会产生一个可执行文件,文件名为php.将它 到 /usr/local/bin 下.在终端方式执行php程序:
php -q onlinnum.php
PHP 原本是应用在网页应用的﹐因此它会送出 HTML 的HEADER﹐但是在此我们是要将 PHP 用作 Shell Script﹐"-q" 就是表示不要送 出 HEADER 的意思.你可以试试看不加上 -q 的显示结果。此时你已经可以在终端方式下执行PHP 代码了。 linux命令：cron daemon
这是一个系统中常驻的服务，功能在于执行例行性的工作，如每天一次或每月一 次检查磁盘。cron daemon 会在每分钟检查一次排定的工作表（crontab），看看是否有要执行的指令，所有的输出会以mail寄给用户。
设置 crontab
命令：crontab -e
该命令呼叫vi编辑器来编辑执行的清单。例如
Ⅱ 了解PHP-FPM
在服务器上，当我们查看php进程时，全都是php-fpm进程，大家都知道这个就是php的运行环境，那么，它到底是个什么东西呢？
PHP-FPM，就是PHP的FastCGI管理器，用于替换PHP FastCGI的大部分附加功能，在PHP5.3.3后已经成为了PHP的标配。
有小伙伴要问了，FastCGI又是什么鬼？CGI程序又叫做“通用网关接口”，就是让Web服务器和你的应用程序进行交互的一个接口。就像nginx中需要配置的fastcgi_pass，一般我们会使用127.0.0.1:9000或者unix:/tmp/php-cgi.sock来配置这个参数。它的意思就是告诉nginx，过来的请求使用tcp:9000端口的监听程序来处理或者使用unix/socket来处理。它们都是指向的PHP运行程序。
再说得通俗一点，我们运行php脚本用的是
php-fpm就相当于是这个php命令。nginx通过fastcgi_pass来运行php $nginx_root(nginx配置文件中网站根目录root配置)下的index.php。所以，如果你用的是python或者其他什么语言，都可以用它们的cgi程序来让nginx调用。
FastCGI和CGI又有什么不同呢？FastCGI是启动一个socket接口，服务器应用不需要自己去运行php，只需要向这个socket接口提交请求就可以了。
php-fpm在编译php时需要添加--enable-fpm。一些通用的集成安装包如lnmp、phpStudy等都会默认编译并使用php-fpm，毕竟是标配。
上文中说过nginx可以使用127.0.0.1:9000和unix:/tmp/php-cgi.sock这两种方式来调用php-fpm。它们有什么区别呢？
前者，一般带9000端口号的，是tcp形式的调用。也就是php-fpm启动了一个监听进程对9000端口进行监听。它会调起一个tcp/ip服务，nginx在调用的时候会走一次tcp请求流程，也就是3次握手4次挥手，会走到网络七层中的第四层传输层。相对来说这种方式性能会稍差一点，启动php-fpm后使用nestat查看端口中会出现9000端口的占用。
后者，使用的是unix套接字socket服务，通过sock文件来交换信息，性能相对好一些，因为它没有tcp连接过程，也不会有9000端口的占用。
对于高负载大访问量的网站还是推荐使用unix方式，对于普通小网站来说，无所谓使用哪个都可以，tcp方式反而更容易配置和理解，也是php-fpm.conf中默认的监听方式。
php-fpm.conf配置中的listen属性用来配置监听，这里的配置要和nginx中的一致，使用tcp的就监听127.0.0.1:9000，使用unix的就设置成/tmp/php-cgi-56.sock。
以下内容摘自官方文档：
===========
各自媒体平台均可搜索【硬核项目经理】
Ⅲ docker-compose启动php-fpm报错问题
当你的机子关闭了ipv6启动php-fpm会出现：
address family not supported by protocol
鲁莽解决方法用命令 find / -name zz-docker.conf 找到配置文件位置
直接修改listen = [::]:9000 为 listen = 0.0.0.0:9000
官方DockerFIle:
https://github.com/docker-library/php/blob//7.0/fpm/alpine/Dockerfile
一般正确做法是修改建立新的dockerfile,
sed "s/[::]:/0.0.0.0:/g" zz-docker.conf
(/var/lib/docker/aufs/diff//usr/local/etc/php-fpm.d/zz-docker.conf)
另外解决方法就是不用compose，而是建立Dockerfile文件，里面跑ubuntu,nginx等，然后顺便安装phpfpm，相当于一个镜像，这样和外部本机ipv6环境无关啦。
Ⅳ php5.4.6怎样重启php-fpm
php5.4中php-fpm怎么重启？
php 5.3.3以后 源码中已经内嵌了 php-fpm，不用象以前的php版本一样专门打补丁了，只需要在configure的时候添加编译参数即可。
关于php-fpm的编译参数有 –enable-fpm –with-fpm-user=www –with-fpm-group=www –with-libevent-dir=libevent位置。
但是，php 5.3.3以后 的php-fpm 不再支持 php-fpm 以前具有的 /usr/local/php/sbin/php-fpm (start|stop|reload)等命令，需要使用信号控制：
master进程可以理解以下信号：
INT, TERM 立刻终止
QUIT 平滑终止
USR1 重新打开日志文件
USR2 平滑重载所有worker进程并重新载入配置和二进制模块
有了以上信号，php-fpm进程重启就方便多了。
例子：
php-fpm 关闭：
代码示例:
kill -INT `cat /usr/local/php/var/run/php-fpm.pid`
php-fpm 重启：
代码示例:
kill -USR2 `cat /usr/local/php/var/run/php-fpm.pid`
说明：
cat部分是php-fpm的进程号，可能是我用的5.4的问题。没有用php-fpm.pid ，就没有这个文件。
可以用 ps aux | grep php-fpm，使用第一个进程的进程号，测试可行。
Ⅳ mac配置php-fpm，nginx运行多版本php
1、brew 安装 php5.6 php5.7 nginx
2、配置php-conf
3、配置虚拟主机
安装好brew
用brew 命令安装，如果速度太慢或访问不了，自行goole brew 换源
brew search php 查看可用的php版本
brew install [email protected] 安装php5.6
brew install [email protected] 安装php5.6
brew install nginx 安装nginx
1、修改php5.6 php-fpm的端口为9056
cd usr/local/etc/php/5.6 # 到php5.6的目录下
vi php-fpm.conf # 修改文件
listen = 127.0.0.1:9056 # 修改此端口
daemonize = yes # 修改为允许后台启动php-fpm
2、修改php5.6 php-fpm的端口为9070
cd /usr/local/etc/php/7.1/php-fpm.d # 到php7.1的目录下
vi www.conf # 修改端口
listen = 127.0.0.1:9056 # 修改此端口
vi php-fpm.conf # 修改文件
daemonize = yes # 修改为允许后台启动php-fpm
3、启动php-fpm
cd /usr/local/sbin # 到此目录，建立两个软链接指向不同版本的php
切换到root用户
./php-fpm56
./php-fpm71
启动后可看到php-fpm的进程，则成功
ps-ef | grep php-fpm
cd /usr/local/etc/nginx/ # 到nginx的目录下
复制默认的配置文件到server下（此目录用来存虚拟主机文件）
这里我在server创建了这两个
vi local.phpinfo56.com.conf # 修改本地域名和nginx代理到php-fpm端口，按照这种方法修改另一个
nginx # 启动nginx
nginx -s reload # 修改配置文件，重新加载nginx
vi /etc /hosts # 修改host 加上映射关系
cd /usr /local/var/www # 在此目录下建立一个index.php
echo "<?php phpinfo();" > index.php
在浏览器访问可看到
Ⅵ PHP进程管理三种模式
ondemand：按请示创建进程数；
dynamic:初始化启动number进程数；
static：固定启动进程数；
php-fpm进程管理一共有三种模式： ondemand、static、dynamic ，我们可以在同一个fpm的master配置三种模式，看下图1。php-fpm的工作模式和nginx类似，都是一个master，多个worker模型。每个worker都在accept本pool内的监听套接字（linux已不存在惊群现象）。
ondemand
在php-fpm启动的时候，不会给这个pool启动任何一个worker，是按需启动，当有连接过来才会启动。
配置文件（我的配置文件地址为：/usr/local/php/etc/php-fpm.conf）
当前pool的名字为test
原理
ondemand原理图
1. 从上图可以看出，新建worker的触发条件是连接的到来，而不是实际的请求（例如，只进行连接比如telnet，不发请求数据也会新建worker）
2. worker的数量受限于pm.max_children配置，同时受限全局配置process.max（准确的说，三种模式都受限于全局配置）
3.1秒定时器作用
找到空闲worker，如果空闲时间超过pm.process_idle_timeout大小，关闭。这个机制可能会关闭所有的worker。
配置项要求
1. pm.max_children> 0
2. pm.process_idle_timeout> 0，如果不设置，默认10s
优缺点
优点：按流量需求创建，不浪费系统资源（在硬件如此便宜的时代，这个优点略显鸡肋）
缺点：由于php-fpm是短连接的，所以每次请求都会先建立连接，建立连接的过程必然会触发上图的执行步骤，所以，在大流量的系统上master进程会变得繁忙，占用系统cpu资源，不适合大流量环境的部署
dynamic
在php-fpm启动时，会初始启动一些worker，在运行过程中动态调整worker数量，worker的数量受限于pm.max_children配置，同时受限全局配置process.max
当前pool的名字为test
原理
dynamic原理图
1. 1秒定时器作用
检查空闲worker数量，按照一定策略动态调整worker数量，增加或减少。增加时，worker最大数量<=max_children· <=全局process.max；减少时，只有idle >pm.max_spare_servers时才会关闭一个空闲worker。
idle > pm.max_spare_servers，关闭启动时间最长的一个worker，结束本次处理
idle >= pm.max_children，打印WARNING日志，结束本次处理
idle < pm.max_children，计算一个num值，然后启动num个worker，结束本次处理
配置项要求
1. pm.min_spare_servers/pm.max_spare_servers有效范围(0,pm.max_children]
2. pm.max_children> 0
3. pm.min_spare_servers<=pm.max_spare_servers
4. pm.start_servers有效范围[pm.min_spare_servers,pm.max_spare_servers]如果没有配置，默认pm.min_spare_servers + (pm.max_spare_servers - pm.min_spare_servers) / 2
优缺点
优点：动态扩容，不浪费系统资源，master进程设置的1秒定时器对系统的影响忽略不计；
缺点：如果所有worker都在工作，新的请求到来只能等待master在1秒定时器内再新建一个worker，这时可能最长等待1s；
static
php-fpm启动采用固定大小数量的worker， 在运行期间也不会扩容，虽然也有1秒的定时器，仅限于统计一些状态信息，例如空闲worker个数，活动worker个数，网络连接队列长度等信息。
当前pool的名字为test
原理
配置项要求
1、pm.max_children> 0 必须配置，且只有这一个参数生效
优缺点
如果配置成static，只需要考虑max_children的数量，数量取决于cpu的个数和应用的响应时间，我司配置的是50。
我司不考虑动态的增加减少那么十几个或者几十个worker，我们的内存没有紧张到这个程度，所以，我们一步到位，把worker数配置到支持最大流量，（哈哈，50也是随便定的，足矣足矣呢）
最后我们再介绍下worker的工作流程
fastcgi与php-fpm的关系一句话解读：fastcgi只是通信应用协议，php-fpm就是实现了fastcig协议，并嵌入了一个 PHP 解释器。
Ⅶ 启动php-fpm为什么有启动了多个进程
php-fpm的两种进程管理模式 php-fpm的进程数也是可以根据设置分为动态和静态的。 一种是直接开启指定数量的php-fpm进程，不再增加或者减少； 另一种则是开始的时候开启一定数量的php-fpm进程，当请求量变大的时候，动态的增加php-fpm进程数到上限，当空闲的时候自动释放空闲的进程数到一个下限。 这两种不同的执行方式，可以根据服务器的实际需求来进行调整。 这里先说一下涉及到这个的几个参数吧，他们分别是pm、pm.max_children、pm.start_servers、pm.min_spare_servers和pm.max_spare_servers。 pm表示使用那种方式，有两个值可以选择，就是static（静态）或者dynamic（动态）。 在更老一些的版本中，dynamic被称作apache-like。这个要注意看配置文件给出的说明了。PHP5.3 php-fpm的默认静态处理方式会使得php-cgi的进程长期占用内存而无法释放，这也是导致nginx出错的原因之 一，因此可以将php-fpm的处理方式改成apache模式。 下面4个参数的意思分别为： pm.max_children：静态方式下开启的php-fpm进程数量。 pm.start_servers：动态方式下的起始php-fpm进程数量。 pm.min_spare_servers：动态方式下的最小php-fpm进程数量。 pm.max_spare_servers：动态方式下的最大php-fpm进程数量。 如果dm设置为static，那么其实只有pm.max_children这个参数生效。系统会开启设置的数量个php-fpm进程。 如果dm设置为dynamic，那么pm.max_children参数失效，后面3个参数生效。系统会在php-fpm运行开始的时候启动 pm.start_servers个php-fpm进程，然后根据系统的需求动态在pm.min_spare_servers和 pm.max_spare_servers之间调整php-fpm进程数。 那么，对于我们的服务器，选择哪种执行方式比较好呢？事实上，跟Apache一样，我们运行的PHP程序在执行完成后，或多或少会有内存泄露的问题。 这也是为什么开始的时候一个php-fpm进程只占用3M左右内存，运行一段时间后就会上升到20-30M的原因了。所以，动态方式因为会结束掉多余的进程，可以回收释放一些内存，所以推荐在内存较少的服务器或者VPS上使用。具体最大数量根据 内存/20M 得到。比如说512M的VPS，建议pm.max_spare_servers设置为20。至于pm.min_spare_servers，则建议根据服务器的负载情况来设置，比较合适的值在5~10之间。 然后对于比较大内存的服务器来说，设置为静态的话会提高效率。因为频繁开关php-fpm进程也会有时滞，所以内存够大的情况下开静态效果会更好。数量也可以根据内存/30M 得到。比如说2GB内存的服务器，可以设置为50；4GB内存可以设置为100等。
Ⅷ docker php-fpm 一直重启问题处理
使用 docker-compose up -d 启动 php-fpm 容器后会发现容器成功启动之后会马上关闭。由于设置了 restart: always 会导致容器再次启动然后关闭
官方 php-fpm : 7.1 镜像，使用自定义的 php-fpm 配置。
php-fpm 配置是从现有生产服务器上复制过来的。配置没有问题。
看log，发现fpm正常启动了，然后马上就退出
跟镜像中自带的 php-fpm.conf 比较发现镜像中使用 daemonize = no ，而我自定义配置中 daemonize = yes 是后台运行的。
那么很明显官方镜像是故意使用 daemonize = no 不让 fpm 在后台中运行，进而阻止容器退出
修改 php-fpm.conf 中如下
daemonize = no
Ⅸ 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()，具体逻辑这里不再展开，比较容易理解。
原文出处： https://www.fanhao.com/2017/10/internal-php-fpm.html
Ⅹ 启动php-fpm时是怎么加载php.ini
php.ini：决定php语言运行的环境，支持扩展的模块,开发环境的配置
php-fpm.conf：进程控制管理器配置文件，控制php-cgi的进程数，常驻内存，提高web服务的响应速率，php-cgi运行时会加载这两个配置文件。