phpfpmcpu
❶ 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导致CPU占用率100%
各个地方打个日志,判断下是哪个地方慢了,然后才能进行优化。根据以往的经验是表中的数据量太大,读取太慢导致的,此时加个索引能解决
❸ 服务器程序源代码分析之二: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设置多少合适
1 那么,对于我们的服务器,选择哪种执行方式比较好呢?事实上,跟Apache一样,我们运行的PHP程序在执行完成后,或多或少会有内存泄露的问题。这也是为什么开始的时候一个php-fpm进程只占用3M左右内存,运行一段时间后就会上升到20-30M的原因了。所以,动态方式因为会结束掉多余 的进程,可以回收释放一些内存,所以推荐在内存较少的服务器或者VPS上使用。具体最大数量根据 内存/20M 得到。比如说512M的VPS,建议pm.max_spare_servers设置为20。至于pm.min_spare_servers,则建议根据服务器的负载情况来设置,比较合适的值在5~10之间。
2 然后对于比较大内存的服务器来说,设置为静态的话会提高效率。因为频繁开关php-fpm进程也会有时滞,所以内存够大的情况下开静态效果会更好。数量也可以根据 内存/30M 得到。比如说2GB内存的服务器,可以设置为50;4GB内存可以设置为100等
❺ 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 解释器。
❻ 升级php7.3 linux服务器cpu 突然很高
1、通过宝塔面板安装的建站环境是LNMP,使用的Nginx 1.16.1、MySQL 5.5.62、PHP-7.0。2、优化PHP7.0设置。先进入到PHP7.0管理页面。首先先安装一个opcache缓冲器,用于加速PHP脚本,其他的就都按默认的来吧,毕竟安装的扩展太多容易影响性能。修改max_execution_time时间为20.性能调整。这里可以根据自己服务器配置进行设置,宝塔面板比较人性化,会根据你的服务器配置设置推荐方案。可以根据自己服务器内存大小进行计算,一般一个php-fpm进程占用内存30M左右,以1024MB内存1G内存)来计算,大概可以设置34个并发。使用的就是1核1G内存配置的服务器,安装宝塔面板后推荐的是40并发,用不到那么高的并发,所以设置了20并发的方案,并把max_spare_servers数字调整成了14。
❼ 请教php并发导致cpu占用100%的问题
简单粗暴的方法升级服务器,高级点的优化代码 优化数据库 做负载均衡 添加一些内存储存类的扩展程序。当然数据库太垃圾你就别想那么多了