php-fpm多实例,php-fpm多实例提升系统吞吐量和服务器资源利用率

通过在12核CPU和16GB内存的服务器上部署PHP-FPM多实例策略,解决QPS瓶颈问题。作者调整了php-fpm配置,增加了nginx轮询,监控各项指标,结果显示响应时间提高,错误减少,资源利用率提升。此方法旨在通过多实例利用闲置资源,增强服务器性能。
摘要由CSDN通过智能技术生成

业务的系统结构是nginx+php-fpm,服务器是12核cpu、16G的内存,工作中cpu、内存、io、网络利用率都不高,但QPS就是跑不上去,超过800就会有少量错误并且性能下降,push瞬间服务就会抖动。排除了依

业务的系统结构是nginx+php-fpm,服务器是12核cpu、16G的内存,工作中cpu、内存、io、网络利用率都不高,但QPS就是跑不上去,超过800就会有少量错误并且性能下降,push瞬间服务就会抖动。排除了依赖的资源mc、redis原因后,那剩下的就是nginx和php-fpm本身,继续分析,nginx用的是tengine2.1.2,之前做cache时并发连接数测到30万、QPS1.5万没出过问题,那最有可能就是php-fpm本身遇到了瓶颈了。对于php-fpm,之前将进程数从128调到了256,继续加大并不是办法,可能根本就不是进程数的问题了,后来多次思索,果断效仿tomcat多实例的方法对php-fpm做多实例,想着最大限度的利用服务器闲散的cpu、内存、io、网络,提高单台服务器的吞吐量。

调整思路及步骤:

1、新建php-fpm的配置文件php-fpm2.conf

第1个实例用的9000端口,第2个实例用9001端口,修改后的配置文件(php-fpm2.conf)如下:[global]

pid = run/php-fpm9001.pid

error_log = /data1/var/logs/php-fpm/error9001.log

log_level = warning

emergency_restart_threshold = 10

emergency_restart_interval = 1m

process_control_timeout = 5s

daemonize = yes

[www]

listen = 127.0.0.1:9001

listen.backlog = -1

listen.allowed_clients = 127.0.0.1

user = www

group = www

pm = static

pm.max_children = 256

pm.max_requests = 1024

request_terminate_timeout = 10

request_slowlog_timeout = 5

slowlog = /data1/var/logs/php-fpm/slow9001.log

rlimit_files = 65535

rlimit_core = 0

chroot =

chdir =

catch_workers_output = yes

pm.status_path = /php_status9001

指定配置文件的启动命令如下,同步更新加入到服务管理/etc/init.d/php-fpm2。/usr/local/php-fpm/sbin/php-fpm  -y  /usr/local/php-fpm/etc/php-fpm2.conf

2、启动服务查看9001端口以及进程

3、修改nginx的配置文件,增加轮训upstream

修改nginx的配置文件,增加轮训的upstream,将fastcgi_pass指向改为upstream名称,日志中添加$upstream_addr、$upstream_response_time字段便于分析问题,具体修改如下:upstream phpcgis {

server 127.0.0.1:9000 max_fails=10 fail_timeout=5s; #在5s内出现10次错误,惩罚5s钟不使用这个server

server 127.0.0.1:9001 max_fails=10 fail_timeout=5s;

keepalive_timeout 65s;

}

fastcgi_pass    phpcgis;

4、用./nginx -t测试一下配置文件,将服务reload并查看日志

5、服务器和业务日志的各指标监控数据如下

a、nginx请求日志的平均响应时间

fb2cea189f1ae4ff163225f82f2e6ba5.png

b、业务日志的502和504情况

98bade1d74c540f99a65b8e2b9e8e303.png

c、cpu的负载情况

fa6aef603f2773c9e06ce149ddbca0f8.png

d、服务器内存的使用情况

aceb1cbc739492eec6913ae694c307c2.png

整体总结:从数据上看,平均响应时间稍有提高,502和504超时类错误消失,内存利用率增加,cpu变化不大。其实此类调整,从某种意义上看,相当于增加了一台服务器,多了一个php的池子,利用多实例在服务器层面补齐php-fpm本身的短板,增大服务器资源的利用率。对于结果,业务承接能力肯定增大,至于是不是倍数关系还待测试。

©本站文章(技术文章和tank手记)均为社长"矢量比特"工作.实践.学习中的心得原创或手记,请勿转载!

喜欢 (16) or

分享 (0)

欢迎扫描关注微信公众号【运维网咖社】

4fd772971148edf5ba96516f24284784.png

社长"矢量比特",曾就职中软、新浪,现任职小米,致力于DevOps运维体系的探索和运维技术的研究实践.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值