php-fpm性能优化实例分析

导言

Web服务器的CPU指标和MEM指标异常,不稳定?可能是PHP-FPM进程重启机制的问题导致的,一同和百度外卖探索下如何优化吧。

摘要

通过优化PHP-FPM进程重启机制,改善线上服务器CPU_IDLE和MEM_USED波动的问题,使服务器资源利用率更加平滑可靠。

背景

外卖交易服务集群报出在监控图上CPU_IDLE波动剧烈,如图所示。

事实上一直以来,不仅PU_IDLE存在一定的波动,MEM_USED的周期性断崖式下降再回升也早已司空见惯。那么CPU_IDLE与MEM_UESD的波动是否存在关联,追溯这种现象产生的原因,我们就必须理解PHP-FPM进程管理器的机制。

原理

在PHP5.3.3版本中,PHP-FPM正式被官方收编,作为FastCGI管理器,支持平滑停止启动进程、slow-log、动态进程、运行状态等特性。

PHP-FPM进程管理支持三种方式:static、dynamic、ondemand。我们选用的是static方式,即PHP-FPM生成固定数量的FastCGI进程,这种方式比较简单,避免了频繁开启关闭进程的开销。(在线下虚拟机环境中,进程管理可以配置成ondemand,既降低了内存需求又避免了进程数量不够用)

回到面临的问题上,CPU_IDLE和MEM_USED的周期性波动是如何产生的。首先这是一种所有的集群都存在的现象,然后交易服务集群表现尤为突出。在排查了应用程序(比如日志采集程序、定时脚本)的影响后,思路落在了PHP-FPM的一个关键参数上:max_requests。

max_requests这个参数使FastCGI进程在处理一定数量的请求后自动重启,以此避免第三方扩展内存泄漏产生破坏性影响。打开线上配置,发现外卖交易服务集群中配置该参数过小,为1000,这便造成了在请求高峰期,FastCGI频繁重启,对CPU产生了负担。于是将max_requests参数调整为10000后,CPU_IDLE表现得到了改善,如图。

但是经过观察发现,CPU_IDLE和MEM_USED周期性波动的问题并没有根除,效果如图。

这很好理解,我们调大max_requests参数,但是FastCGI重启机制依然生效,每个请求都会计数,当计数到达max_request之后,cgi进程会执行 fcgi_finish_request退出进程,子进程退出,fpm-master进程会收到SIGCHLD信号,运行fpm_children_bury重启进程,重启的方式是fork一个子进程。

FastCGI进程通过unix socket承接Nginx请求,负载较为均衡,生产环境流量大,PHP进程数配置较大,数以百计的FastCGI会在同一时间到达 max_requests上限而进行重启,这便造成了CPU_IDLE和MEM_USED周期性波动。

优化

max_requests的初衷是为了避免第三方扩展引起的内存泄漏问题,虽然线上环境使用的扩展经过分析和测试,并没有严重的内存泄漏问题,但是由于扩展内部使用的第三方库太多,并无法完全避免内存泄漏问题,同时max_requests机制很适合FastCGI多进程环境,以较小的代价,换取内存泄漏的长治久安。

为了避免CPU_IDLE和MEM_USED周期波动,同时保持max_requests机制,需要在PHP-FPM源码上稍作修改。FastCGI进程在启动时,设置max_requests,此时只要将max_requests配置参数散列开,使FastCGI进程分别配置不同的值,即可达到效果。

具体代码在sapi/fpm/fpm/fpm.c,修改如下:

php_mt_srand(GENERATE_SEED()); *max_requests=fpm_globals.max_requests+php_mt_rand()&8191;

总结

经过修改上线,对比效果见下图

至此CPU_IDLE和MEM_USED已经告别了周期性波动,避免了CPU计算资源产生浪涌效果,内存占用数据也更加真实可靠。

标签:PHP 发布于:2019-11-12 21:09:37