泽民博客 ☰ Menu

Php-fpm运行原理

cgi的历史



早期的webserver只处理html等静态文件，但是随着技术的发展，出现了像php等动态语言。
webserver处理不了了，怎么办呢？那就交给php解释器来处理吧！
交给php解释器处理很好，但是，php解释器如何与webserver进行通信呢？



为了解决不同的语言解释器(如php、python解释器)与webserver的通信，于是出现了cgi协议。只要你按照cgi协议去编写程序，就能实现语言解释器与webwerver的通信。如php-cgi程序。



fast-cgi的改进



有了cgi协议，解决了php解释器与webserver通信的问题，webserver终于可以处理动态语言了。但是，webserver每收到一个请求，都会去fork一个cgi进程，请求结束再kill掉这个进程。这样有10000个请求，就需要fork、kill php-cgi进程10000次。



有没有发现很浪费资源？



于是，出现了cgi的改良版本，fast-cgi。fast-cgi每次处理完请求后，不会kill掉这个进程，而是保留这个进程，使这个进程可以一次处理多个请求。这样每次就不用重新fork一个进程了，大大提高了效率。



2、php-fpm是什么



php-fpm即php-Fastcgi Process Manager.
php-fpm是 FastCGI 的实现，并提供了进程管理的功能。
进程包含 master 进程和 worker 进程两种进程。
master 进程只有一个，负责监听端口，接收来自 Web Server 的请求，而 worker 进程则一般有多个(具体数量根据实际需要配置)，每个进程内部都嵌入了一个 PHP 解释器，是 PHP 代码真正执行的地方。
具体的流程如下：
FPM 的 master 进程接收到请求
master 进程根据配置指派特定的 worker 进程进行请求处理，如果没有可用进程，返回错误，这也是我们配合 Nginx 遇到502错误比较多的原因。
worker 进程处理请求，如果超时，返回504错误
请求处理结束，返回结果
Nginx 提供了 fastcgi 模块来将 http 请求映射为对应的 fastcgi 请求

3,配置Nginx+Php-fpm
#当请求网站下php文件的时候，反向代理到php-fpm
location ~ .php$ {
include /usr/local/etc/nginx/fastcgi.conf; #加载nginx的fastcgi模块
fastcgi_intercept_errors on;
fastcgi_pass 127.0.0.1:9000; #nginx fastcgi进程监听的IP地址和端口
}



1.与Nginx使用Unix域Socket通信(Nginx和php-fpm在同一台服务器)



　　Unix域Socket因为不走网络，的确可以提高Nginx和php-fpm通信的性能，但在高并发时会不稳定。



　　Nginx会频繁报错：connect() to unix:/dev/shm/php-fcgi.sock failed (11: Resource temporarily unavailable) while connecting to upstream



　　可以通过下面两种方式提高稳定性：
　　1）调高nginx和php-fpm中的backlog
　　 配置方法为：在nginx配置文件中这个域名的server下，在listen 80后面添加default backlog=1024。
　　同时配置php-fpm.conf中的listen.backlog为1024，默认为128。
　　2）增加sock文件和php-fpm实例数
　　再新建一个sock文件，在Nginx中通过upstream模块将请求负载均衡到两个sock文件背后的两套php-fpm实例上。



2.php-fpm参数调优



　　pm = dynamic; 表示使用哪种进程数量管理方式



　　　　dynamic表示php-fpm进程数是动态的，最开始是pm.start_servers指定的数量，如果请求较多，则会自动增加，保证空闲的进程数不小于pm.min_spare_servers，如果进程数较多，也会进行相应清理，保证多余的进程数不多于pm.max_spare_servers



　　　　static表示php-fpm进程数是静态的, 进程数自始至终都是pm.max_children指定的数量，不再增加或减少



　　pm.max_children = 300; 静态方式下开启的php-fpm进程数量
　　pm.start_servers = 20; 动态方式下的起始php-fpm进程数量
　　pm.min_spare_servers = 5; 动态方式下的最小php-fpm进程数量
　　pm.max_spare_servers = 35; 动态方式下的最大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进程数



　　　　那么，对于我们的服务器，选择哪种pm方式比较好呢？事实上，跟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，则建议根据服务器的负载情况来设置，比较合适的值在5~10之间。



　　　　在4G内存的服务器上200就可以(我的1G测试机，开64个是最好的，建议使用压力测试获取最佳值)



　　pm.max_requests = 10240;



　　　　nginx php-fpm配置过程中最大问题是内泄漏出问题：服务器的负载不大，但是内存占用迅速增加，很快吃掉内存接着开始吃交换分区，系统很快挂掉！其实根据官方的介绍，php-cgi不存在内存泄漏，每个请求完成后php-cgi会回收内存，但是不会释放给操作系统，这样就会导致大量内存被php-cgi占用。
　　　　



　　　　官方的解决办法是降低PHP_FCGI_MAX_REQUESTS的值，如果用的是php-fpm，对应的php-fpm.conf中的就是max_requests，该值的意思是发送多少个请求后会重启该线程，我们需要适当降低这个值，用以让php-fpm自动的释放内存，不是大部分网上说的51200等等，实际上还有另一个跟它有关联的值max_children，这个是每次php-fpm会建立多少个进程，这样实际上的内存消耗是max_childrenmax_requests每个请求使用内存，根据这个我们可以预估一下内存的使用情况，就不用再写脚本去kill了。



　　request_terminate_timeout = 30;



　　　　最大执行时间, 在php.ini中也可以进行配置(max_execution_time)



　　request_slowlog_timeout = 2; 开启慢日志
　　slowlog = log/$pool.log.slow; 慢日志路径



　　rlimit_files = 1024; 增加php-fpm打开文件描述符的限制



3.php-fpm的高CPU使用率排查方法



　　1)使用top命令, 直接执行top命令后，输入1就可以看到各个核心的CPU使用率。而且通过top -d 0.1可以缩短采样时间



　　2)查询php-fpm慢日志














grep -v “^$” www.log.slow.tmp cut -d “ “ -f 3,2 sort uniq -c sort -k1,1nr head -n 50


php-fpm对于进程的管理存在两种风格——static和dynamic。



如果设置成static，php-fpm进程数自始至终都是pm.max_children指定的数量，不再增加或减少。



如果设置成dynamic，则php-fpm进程数是动态的，最开始是pm.start_servers指定的数量，如果请求较多，则会自动增加，保证空闲的进程数不小于pm.min_spare_servers，如果进程数较多，也会进行相应清理，保证多余的进程数不多于pm.max_spare_servers。



这两种不同的进程管理方式，可以根据服务器的实际需求来进行调整。



这里先说一下涉及到这个的几个参数，他们分别是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进程数量。


如果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的原因了。



对于内存大的服务器（比如8G以上）来说，指定静态的max_children实际上更为妥当，因为这样不需要进行额外的进程数目控制，会提高效率。因为频繁开关php-fpm进程也会有时滞，所以内存够大的情况下开静态效果会更好。max_children 数量也可以根据 内存/40M 得到，比如8GB内存可以设置为100（,留4G内存给其他应用， 4*1024/40=102.4约等于100），那么php-fpm耗费的内存就能控制在 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，则建议根据服务器的负载情况来设置，比较合适的值在5~10之间。



Unix domain socket 或者 IPC socket是一种终端，可以使同一台操作系统上的两个或多个进程进行数据通信。与管道相比，Unix domain sockets 既可以使用字节流和数据队列，而管道通信则只能通过字节流。Unix domain sockets的接口和Internet socket很像，但它不使用网络底层协议来通信。Unix domain socket 的功能是POSIX操作系统里的一种组件。



Unix domain sockets 使用系统文件的地址来作为自己的身份。它可以被系统进程引用。所以两个进程可以同时打开一个Unix domain sockets来进行通信。不过这种通信方式是发生在系统内核里而不会在网络里传播。



TCP和unix domain socket方式对比



TCP是使用TCP端口连接127.0.0.1:9000



Socket是使用unix domain socket连接套接字/dev/shm/php-cgi.sock（很多教程使用路径/tmp，而路径/dev/shm是个tmpfs，速度比磁盘快得多



fastcgi进程管理器php-fpm自身初始化，启动主进程php-fpm和启动start_servers个fastcgi子进程。主进程php-fpm主要是管理fastcgi子进程，监听9000端口，fastcgi子进程等待请求。当客户端请求到达nginx时，nginx通过location指令，将所有以php为后缀的文件都交给 127.0.0.1:9000 来处理。php-fpm选择并连接到一个fastcgi子进程，并将环境变量和标准输入发送到fastcgi子进程。fastcgi子进程完成处理后将标准输出和错误信息返回。当fastcgi子进程关闭连接时，请求便告处理完成，等待下次处理。



在Linux中，nginx服务器和PHP-fpm可以通过tcp socket和unix socket两种方式实现。



unix socket是一种终端，可以使同一台操作系统上的两个或多个进程进行数据通信。这种方式需要再nginx配置文件中填写php-fpm的pid文件位置，效率要比tcp socket高。



tcp socket的优点是可以跨服务器，当nginx和php-fpm不在同一台机器上时，只能使用这种方式。



windows系统只能使用tcp socket的通信方式



配置方法
tcp socket
tcp socket通信方式，需要在nginx配置文件中填写php-fpm运行的ip地址和端口号。



location ~ .php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /var/www/website$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
}
unix socket
unix socket通信方式，需要在nginx配置文件中填写php-fpm运行的pid文件地址。



location ~ .php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /var/www/website$fastcgi_script_name;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
}



我们知道web服务器与PHP应用之间通过SAPI接口进行交互数据。PHP提供了多种SAPI接口，例如 apache2hander、fastcgi、cli等等。当然，php-fpm也是其中一种。相比其他接口，php-fpm运用更加广泛。



php-fpm是一种master（主）/worker（子）多进程架构，与nginx设计风格有点类似。master进程主要负责CGI及PHP环境初始化、事件监听、子进程状态等等，worker进程负责处理php请求。
在介绍运行原理之前，我们先了解下它的几种运行模式。



运行模式
php-fpm支持三种运行模式，分别为static、ondemand、dynamic，默认为dynamic 。
static : 静态模式，启动时分配固定的worker进程。
ondemand: 按需分配，当收到用户请求时fork worker进程。
dynamic: 动态模式，启动时分配固定的进程。伴随着请求数增加，在设定的浮动范围调整worker进程。



这三种模式各有千秋，大家可以根据不同的环境调整相应的配置。



下面进入本文主题，着重介绍php-fpm运行原理。



运行原理
php-fpm采用master/worker架构设计，前面简单地描述master和worker进程模块的功能。下面将详细讲解这两个模块的运行原理。



master进程
master进程工作流程分为4个阶段，如下图：
这里写图片描述



  1. cgi初始化阶段：分别调用fcgi_init()和 sapi_startup()函数，注册进程信号以及初始化sapi_globals全局变量。

  2. php环境初始化阶段：由cgi_sapi_module.startup 触发。实际调用php_cgi_startup函数，而php_cgi_startup内部又调用php_module_startup执行。 php_module_startup主要功能：a).加载和解析php配置；b).加载php模块并记入函数符号表(function_table)；c).加载zend扩展 ; d).设置禁用函数和类库配置；e).注册回收内存方法；

  3. php-fpm初始化阶段：执行fpm_init()函数。负责解析php-fpm.conf文件配置，获取进程相关参数（允许进程打开的最大文件数等）,初始化进程池及事件模型等操作。

  4. php-fpm运行阶段：执行fpm_run() 函数，运行后主进程发生阻塞。该阶段分为两部分：fork子进程 和 循环事件。fork子进程部分交由fpm_children_create_initial函数处理（ 注：ondemand模式在fpm_pctl_on_socket_accept函数创建）。循环事件部分通过fpm_event_loop函数处理，其内部是一个死循环，负责事件的收集工作。



worker进程
worker进程分为 接收客户端请求、处理请求、请求结束三个阶段。
这里写图片描述



  1. 接收客户端请求：执行fcgi_accept_request函数，其内部通过调用accept 函数获取客户端请求。



//请求锁
FCGI_LOCK(req->listen_socket);
req->fd = accept(listen_socket, (struct sockaddr *)&sa, &len);
//释放锁
FCGI_UNLOCK(req->listen_socket);
从上面的代码，可以注意到accept之前有一个请求锁的操作，这么设计是为了避免请求出现“惊群”的现象。当然，这是一个可选的选项，可以取消该功能。



  1. 处理请求阶段：首先，分别调用fpm_request_info、php_request_startup获取请求内容及注册全局变量($_GET、$_POST、$_SERVER、$_ENV、$_FILES)；然后根据请求信息调用php_fopen_primary_script访问脚本文件；最后交给php_execute_script执行。php_execute_script内部调用zend_execute_scripts方法将脚本交给zend引擎处理。

  2. 请求结束阶段：执行php_request_shutdown函数。此时 回调register_shutdown_function注册的函数及__destruct()方法，发送响应内容、释放内存等操作。



php-cgi是语言的解释器。之前是请求到来时候，都要新开一个进程启动php-cgi,重新载入配置、数据结构，初始化运行环境.更新PHP配置之后，需要重启PHP-cgi，配置才能生效。
php-fpm实现了fastcgi的管理器。常驻内存，负责管理各个php-cgi进程。可以提升运行效率，实现平滑重启。



FastCGI是一个常驻型的CGI，它可以一直执行，只要激活后，不会每次都要花费时间去fork一次（这是CGI最为人诟病的fork-and-execute模式）。它还支持分布式的运算，即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。



FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。我们知道，CGI解释器的反复加载是CGI性能低下的主要原因，如果CGI解释器保存在内存中并接受FastCGI进程管理器调度，那么就可以提供良好的性能、伸缩性等。



优点：





  1. FastCGI具有语言无关性；




  2. FastCGI独立于核心web服务器运行，提供了一个比API更安全的环境。APIs把应用程序的代码与核心的web服务器链接在一起，这意味着在一个错误的API的应用程序可能会损坏其他应用程序或核心服务器。而恶意的API的应用程序代码甚至可以窃取另一个应用程序或核心服务器的密钥；




  3. FastCGI技术目前支持语言有：C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等。相关模块在Apache, ISS, Lighttpd等流行的服务器上也是可用的；




  4. FastCGI不依赖于任何Web服务器的内部架构，因此即使服务器技术的变化, FastCGI依然稳定不变；





缺点：



因为是多进程，所以比CGI多线程消耗更多的服务器内存，PHP-CGI解释器每进程消耗7至25兆内存，将这个数字乘以50或100就是很大的内存数。



Nginx 0.8.46+PHP 5.2.14(FastCGI)服务器在3万并发连接下，开启的10个Nginx进程消耗150M内存（15M10=150M），开启的64个php-cgi进程消耗1280M内存（20M64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。如果服务器内存较小，完全可以只开启25个php-cgi进程，这样php-cgi消耗的总内存数才500M。



上面的数据摘自Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建胜过Apache十倍的Web服务器(第6版)。



原理：





  1. Web服务器启动时，载入FastCGI进程管理器；




  2. FastCGI进程管理器初始化，启动多个CGI解释器进程(PHP-CGI)并等待来自Web服务器的连接；




  3. 当客户端请求到达Web服务器时，FastCGI进程管理器选择并连接到一个CGI解释器，Web服务器将CGI环境变量和标准输入发送到FastCGI子进程PHP-CGI。




  4. FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回给Web服务器。当FastCGI子进程关闭连接时，请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web服务器中)的下一个连接。而在CGI模式中，PHP-CGI在此便退出了。





但是为什么要重启进程呢？



一般在项目中，我们多多少少都会用到一些 PHP 的第三方库，这些第三方库经常存在内存泄漏问题，如果不定期重启 PHP-CGI 进程，势必造成内存使用量不断增长。因此 PHP-FPM 作为 PHP-CGI 的管理器，提供了这么一项监控功能，对请求达到指定次数的 PHP-CGI 进程进行重启，保证内存使用量不增长。



正是因为这个机制，在高并发的站点中，经常导致 502 错误，我猜测原因是 PHP-FPM 对从 NGINX 过来的请求队列没处理好。不过我目前用的还是 PHP 5.3.2，不知道在 PHP 5.3.3 中是否还存在这个问题。



目前我们的解决方法是，把这个值尽量设置大些，尽可能减少 PHP-CGI 重新 SPAWN 的次数，同时也能提高总体性能。在我们自己实际的生产环境中发现，内存泄漏并不明显，因此我们将这个值设置得非常大（204800）。大家要根据自己的实际情况设置这个值，不能盲目地加大



运行原理
php-fpm采用master/worker架构设计，前面简单地描述master和worker进程模块的功能。下面将详细讲解这两个模块的运行原理。



master进程
master进程工作流程分为4个阶段，如下图：
这里写图片描述



  1. cgi初始化阶段：分别调用fcgi_init()和 sapi_startup()函数，注册进程信号以及初始化sapi_globals全局变量。

  2. php环境初始化阶段：由cgi_sapi_module.startup 触发。实际调用php_cgi_startup函数，而php_cgi_startup内部又调用php_module_startup执行。 php_module_startup主要功能：a).加载和解析php配置；b).加载php模块并记入函数符号表(function_table)；c).加载zend扩展 ; d).设置禁用函数和类库配置；e).注册回收内存方法；

  3. php-fpm初始化阶段：执行fpm_init()函数。负责解析php-fpm.conf文件配置，获取进程相关参数（允许进程打开的最大文件数等）,初始化进程池及事件模型等操作。

  4. php-fpm运行阶段：执行fpm_run() 函数，运行后主进程发生阻塞。该阶段分为两部分：fork子进程 和 循环事件。fork子进程部分交由fpm_children_create_initial函数处理（ 注：ondemand模式在fpm_pctl_on_socket_accept函数创建）。循环事件部分通过fpm_event_loop函数处理，其内部是一个死循环，负责事件的收集工作。



worker进程
worker进程分为 接收客户端请求、处理请求、请求结束三个阶段。
这里写图片描述



  1. 接收客户端请求：执行fcgi_accept_request函数，其内部通过调用accept 函数获取客户端请求。



//请求锁
FCGI_LOCK(req->listen_socket);
req->fd = accept(listen_socket, (struct sockaddr *)&sa, &len);
//释放锁
FCGI_UNLOCK(req->listen_socket);
从上面的代码，可以注意到accept之前有一个请求锁的操作，这么设计是为了避免请求出现“惊群”的现象。当然，这是一个可选的选项，可以取消该功能。



  1. 处理请求阶段：首先，分别调用fpm_request_info、php_request_startup获取请求内容及注册全局变量($_GET、$_POST、$_SERVER、$_ENV、$_FILES)；然后根据请求信息调用php_fopen_primary_script访问脚本文件；最后交给php_execute_script执行。php_execute_script内部调用zend_execute_scripts方法将脚本交给zend引擎处理。

  2. 请求结束阶段：执行php_request_shutdown函数。此时 回调register_shutdown_function注册的函数及__destruct()方法，发送响应内容、释放内存等操作。


Category php