转载至: https://www.cnblogs.com/kenshinobiy/p/7470635.html
PHP-FPM配置及使用总结:
php-FPM是一个PHP FastCGI的管理器,它实际上就是PHP源代码的补丁,旨在将FastCGI进程管理引进到PHP软件包中,我们必须将其patch到PHP源代码中,然后再行编译才能使用。而现在我们可以在PHP 5.3.2及更新版本中直接开启并使用即可,因为PHP从该版本已经将其收入到软件包中,所以其不再是补丁包的存在了。
· 几个概念的理解
· Nginx+PHP配置
· Php-Fpm的操作
一、几个概念的理解
1)、CGI
CGI全称“公共网关接口”(Common Gateway Interface),是HTTP服务器与其它机器上的程序进行通信的接口,其程序须运行在网络服务器上。
NOTE:
CGI可以用任何一种语言编写,只要这种语言具有标准输入、输出和环境变量。
2)、FastCGI
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内存(15M*10=150M),开启的64个php-cgi进程消耗1280M内存(20M*64=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在此便退出了。
在上述情况中,可以想象CGI通常有多慢,每一个Web请求PHP都必须重新解析php.ini、重新载入全部扩展,并重初始化全部数据结构。而使用FastCGI,所有这些都只在进程启动时发生一次。另外,数据库持久连接可以工作。
NOTE:
FastCGI的主要优点是把动态语言和HTTP Server分离开来,所以Nginx与PHP/PHP-FPM经常被部署在不同的服务器上,以分担前端Nginx服务器的压力,使Nginx专一处理静态请求和转发动态请求,而PHP/PHP-FPM服务器专一解析PHP动态请求。
3)、PHP-CGI
PHP-CGI是PHP自带的FastCGI管理器。
PHP-CGI的不足:
1. php-cgi变更php.ini配置后需重启php-cgi才能让新的php-ini生效,不可以平滑重启。
2. 直接杀死php-cgi进程,php就不能运行了(PHP-FPM和Spawn-FCGI就没有这个问题,守护进程会平滑重新生成新的子进程)。
4)、Spawn-FCGI
Spawn-FCGI是一个通用的FastCGI管理服务器,它是lighttpd中的一部份,很多人都用Lighttpd的Spawn-FCGI进行FastCGI模式下的管理工作,不过有不少缺点。而PHP-FPM的出现多少缓解了一些问题,但PHP-FPM有个缺点就是要重新编译,这对于一些已经运行的环境可能有不小的风险(refer),在php 5.3.3可以直接使用PHP-FPM了。
Spawn-FCGI目前已经独成为一个项目,更加稳定一些,也给很多Web 站点的配置带来便利。已经有不少站点将它与nginx搭配来解决动态网页。最新的lighttpd也没有包含这一块了(http://www.lighttpd.NET/search?q=Spawn-FCGI),但可以在以前版本中找到它。在lighttpd-1.4.15
版本中就包含了(http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz),目前Spawn-FCGI的下载地址是http://redmine.lighttpd.Net/projects/spawn-fcgi,最新版本是http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz。
NOTE:
最新的Spawn-FCGI可以到lighttpd.net网站搜索“Spawn-FCGI”找到它的最新版本发布地址。
5)、对比Spawn-FCGI
PHP-FPM的使用非常方便,配置都是在PHP-FPM.ini的文件内,而启动、重启都可以从php/sbin/PHP-FPM中进行。更方便的是修改php.ini后可以直接使用PHP-FPM reload进行加载,无需杀掉进程就可以完成php.ini的修改加载
结果显示使用PHP-FPM可以使php有不小的性能提升。PHP-FPM控制的进程cpu回收的速度比较慢,内存分配的很均匀。
Spawn-FCGI控制的进程CPU下降的很快,而内存分配的比较不均匀。有很多进程似乎未分配到,而另外一些却占用很高。可能是由于进程任务分配的不均匀导致的。而这也导致了总体响应速度的下降。而PHP-FPM合理的分配,导致总体响应的提到以及任务的平均。
二、Nginx+PHP配置
1、进程数优化
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个是最好的,建议使用压力测试获取最佳值)
2、最大请求数优化
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_children*max_requests*每个请求使用内存,根据这个我们可以预估一下内存的使用情况,就不用再写脚本去kill了。
NOTE:
这个用来处理因为PHP解析器或引用的第三方库时,造成的内存泄露问题。
最大请求数:指一个php-fpm的工作进程在处理多少个请求后就终止掉。
3、最长执行时间优化(php.ini)
request_terminate_timeout = 20
NOTE:
这个是用来处理因为PHP执行时间超长而报502错误的解决。
这个时长配置可以在php.ini(max_execution_time)或php-fpm.conf中配置均可,为了不影响全局配置,可在php-fpm.conf中实现。
值得注意的是:需要结合nginx.conf中的max_fail(调大些)和fail_timeout(调小些)一同配置。
nginx.conf:
location ~ .php$ {
…
fastcgi_connect_timeout 180;
fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
…
}
NOTE:
PHP-FPM设置的脚本最大执行时间已经够长了,但执行耗时PHP脚本时,发现Nginx报错变为504错误。这是因为我们修改的只是PHP的配置,Nginx中也有关于与上游服务器通信超时时间的配置factcgi_connect/read/send_timeout。
4、php-fpm高cpu使用排查
top命令 :
直接执行top命令后,输入1就可以看到各个核心的CPU使用率:
sar命令:
sar和iostat命令的安装:
sysstat.x86_64 : The sar and iostat systemmonitoring commands
yum install -y sysstat.x86_64
执行:
$sar -P ALL 1 100
NOTE:
-P ALL表示监控所有核心;
1表示每1秒采集;
100表示采集100次;
5、开启慢日志
slowlog = log/$pool.log.slow
request_slowlog_timeout = 2
NOTE:
上面为开启php-fpm的慢日志,时间阀值2秒;
执行:
grep -v "^$" php.slow.log | cut -d " " -f 3,2 | sort |uniq -c | sort -k1,1nr | head -n 50
NOTE:
sort: 对单词进行排序
uniq -c: 显示唯一的行,并在每行行首加上本行在文件中出现的次数
sort -k1,1nr: 按照第一个字段,数值排序,且为逆序
head –n 10: 取前10行数据
PS:
开启慢日志的目的是为了跟踪分析那条php脚本执行的时间超过了设置的request_slowlog_timeout时长,如果超过这个设置时间,那么该脚本就会被记录下。
三、Php-Fpm的操作
PHP5.3.3下的php-fpm 不再支持php-fpm 以前具有的 /usr/local/php/sbin/php-fpm(start|stop|reload)等命令,需要使用信号控制:
master进程可以理解以下信号
INT, TERM 立刻终止 ;
QUIT 平滑终止 ;
USR1 重新打开日志文件 ;
USR2平滑重载所有worker进程并重新载入配置和二进制模块 ;
示例:
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`
查看php-fpm进程数:
$ps aux | grep -c php-fpm