问题描述
最近有台服务器偶尔会报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的进程数确实有比较明显的变化，但是最高只到了75左右，并没有达到我们设置的pm.max_children的数值。
综上，结合502的特性，猜测：
是否是php-fpm子进程设置为dynamic模式，而我们的空闲进程数上限设置得比较低(目前设置的是35)，然后当请求量增大时，创建子进程的速度跟不上请求增加的速度，进而导致部分请求无法得到响应，从而出现502？
验证猜想
为了验证上面的这个猜测，我在测试环境做了一些尝试，即将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这个配置)，保证请求量增加时，能够有足够的进程来处理请求，不需要在短时间内创建过多进程。