背景：自从有了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？
验证猜想
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？
验证猜想
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：http://jackxiang.com/post/9265/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
只用js如何更有效的获取服务器时间看「百度都能一分钟搜索的面试题」帖子有
一个小习惯让你的代码更完美 PHP中抽出数组成员 评论列表
