标题:[实践Ok]记录一次PHP项目并发太多报502的问题 出处:向东博客 专注WEB应用 构架之美 --- 构架之美,在于尽态极妍 | 应用之美,在于药到病除 时间:Sat, 24 Jun 2017 12:57:42 +0000 作者:jackxiang 地址:http://jackxiang.com/post/9265/ 内容: 背景:自从有了nginx和php-fpm,就有502,这个经验公式有,但是502依然有,三点:1,很多小厂商vps搞了nginx还搞mysql把负载提起来了处理能力下降,业务本来逻辑就复杂处理时间长不说,还搞一些后台PHP调用计算的接口放crontab里面,逻辑运算稍微重点就导致PHP阻塞进程默认就不够用或阻塞后不够用出现502,或还会fd句柄也不够用。二、一下子来了个洪峰,本文讲到的,作者很好。三,配置进程数不当。 pm.start_server #控制服务启动时创建的进程数, pm.min_spare_servers #控制最小备用进程数 pm.max_spare_servers #最大备用进程数 spare_servers翻译成备用进程,不知道合适不适合,如果真这样,那我之前的配置就让人无奈了: pm.min_space_servers 20,pm.max_spare_servers 80,pm.max_children 80,会不会是因为备用的太多才导致502呢? 另外,下面的具体配置里面,注释中给出了计算pm.start_servers默认值的公式: Default Value: min_spare_servers + (max_spare_servers - min_spare_servers) / 2 ——————————————————————————————————— 问题描述 最近有台服务器偶尔会报502错误,虽然量不多,每天就几十个,但是也必须得找到原因,避免让小问题变成大问题。 排查过程 502错误的原因,一般是对用户访问请求的响应超时造成的,一开始以为是请求量太大,超过了服务器目前的负载,但是查看了zabbix监控,发现问题时段的负载、内存、IO都没有非常明显的变化,服务器并没有达到繁忙的状态;查看这个时段请求的并发数,也不高。 然后查看nginx错误日志,发现该时段有如下报错: connect to unix:/dev/shm/phpfpm.socket failed (11: Resource temporarily unavailable) while connecting to upstream 说明还是php-fpm进程不足导致的。 然后再观察问题时段的php-fpm进程数变化情况: 点击在新窗口中浏览此图片 发验证猜想 为了验证上面的这个猜测,我在测试环境做了一些尝试,即将php-fpm的pm.start_servers和pm.max_spare_servers都设置得比较小,然后进行ab测试,观察php-fpm创建子进程的速度,发现果然和猜测的一样,是非常慢的。当请求数比较多时,会因为创建php-fpm子进程的速度太慢,出现502的情况。 解决方案 增大php-fpm的pm.start_servers和pm.max_spare_servers的数值(最关键的是pm.max_spare_servers这个配置),保证请求量增加时,能够有足够的进程来处理请求,不需要在短时间内创建过多进程。现问题时段php-fpm的进程数确实有比较明显的变化,但是最高只到了75左右,并没有达到我们设置的pm.max_children的数值。 综上,结合502的特性,猜测: 是否是php-fpm子进程设置为dynamic模式,而我们的空闲进程数上限设置得比较低(目前设置的是35),然后当请求量增大时,创建子进程的速度跟不上请求增加的速度,进而导致部分请求无法得到响应,从而出现502? 验证猜想 Generated by Jackxiang's Bo-blog 2.1.1 Release