在nginx上跑php容易出现502错误，很多人遇到过这个问题，到底是什么原因导致的呢？
出现502错误后，又有哪些解决办法呢？
本文源起于前段时间处理无线浏览器的一次502报警后总结得来，希望能为大家提供参考。
从报警说起
现象
1、打开静态页面很快，如无线浏览器的更新日志页面，请求云控接口却很慢，报502错误。
2、最开始一周报警1-2次，后来发展到一天报警1次。
处理过程
1、查看错误日志，发现502错误的响应时间都比较长，均为21s左右。见下图：
日志中请求的是云控接口，就是一个读取配置文件然后吐出数据的过程，正常情况下响应时间应该是非常短的。
因此直观猜测是php进程堵死了，云控请求过来时php进程不够用了，从而导致502错误。
使用 netstat -napo | grep "php-fpm" | wc -l 查看了一下当前fastcgi进程个数, 发现已达到php-fpm.conf中pm.max_children的设置值。
重启php-fpm后，报警得以解除，但这并没有找到问题根源，php进程为什么会堵死呢？
2、猜测进程堵死的原因应该是大量的慢请求导致的。在/usr/local/php/etc/php-fpm.conf文件中，发现有关于慢日志的设置：
slowlog = /data/php/log/$pool.log.slow request_slowlog_timeout = 10 request_terminate_timeout = 0
request_terminate_timeout配置的是一个php脚本的最大执行时间，默认是0s。
0s的含义是让php脚本一直执行下去而没有时间限制。
当再次收到报警时，查看php的slow log，果然发现发现大量执行时间超过10s的脚本。慢日志如下：
11-Aug-2014 08:34:53 pool www pid 8683 script_filename = /home/q/system/api.mse.360.cn/src/www/api//index.php0x00000000013d0420 curl_exec() /home/q/system/api.mse.360.cn/src/application/models/bizservice/icon_svc.php:291 0x00000000013cff98 httpRequest() /home/q/system/api.mse.360.cn/src/application/models/bizservice/icon_svc.php:203 0x00000000013cf710 getTitleBySite() /home/q/system/api.mse.360.cn/src/application/models/bizservice/icon_svc.php:33 0x00000000013cf260 getIconAndTitleBySite() /home/q/system/api.mse.360.cn/src/application/controllers/api/IconController.php:25 0x00000000013cf0c0 addSiteAction() /home/q/php/QFrameSmarty/web/QFrameaction.php:46 0x00000000013ce9a0 dispatch() /home/q/php/QFrameSmarty/web/QFrameweb.php:176 0x00000000013ce4b0 dispatch() /home/q/php/QFrameSmarty/web/QFrameweb.php:150 0x00000000013ce190 runController() /home/q/php/QFrameSmarty/web/QFrameweb.php:129 0x00000000013ce018 processRequest() /home/q/php/QFrameSmarty/web/QFrameweb.php:37 0x00000000013cdc50 run() /home/q/system/api.mse.360.cn/src/www/api/index.php:15
终于找到php进程堵死的根源：调用添加icon到浏览器主屏这个接口时，大量的curl抓取页面title执行超时。
慢请求过多导致php进程不能及时释放，所以触发报警。
添加curl的执行超时，上线代码后，php进程终于治“堵”成功，nginx+php-fpm的502报警彻底解除。
为什么会出现502
一般而言，nginx出现502有很多原因，但大都可以归结为资源数量不够用,也就是说后端php-fpm处理有问题。
nginx将正确的客户端请求发给后端的php-fpm进程，由于php-fpm进程的问题导致不能正确解析php代码，最终返回502错误。
1、php-fpm进程数不够用
nginx和fastcgi是通过socket进行连接的,一个php-fpm进程在同一时刻只能响应一个用户请求。它能处理的最大请求数由php-fpm.conf中如下配置决定：
listen.backlog = 128 pm.max_children = 256
这是我们线上服务器的配置，也就是说php-fpm能处理的最大请求数为384。
当客户端的请求数超过这个值时，再试图发送请求会收到Resource temporarily unavailable，这时nginx就会报502错误。
上面提到的业务报警就是由于php-fpm进程数不够用而导致的。
大量慢请求占据了php进程，php-fpm进程数很快达到峰值。php-fpm被卡死不能处理新的请求时，nginx并不会收到请求被拒绝的类似信息，而是把请求积压在socket上；
此时浏览器所得到的响应就是一个“正在等待响应”的提示，除非socket报错或浏览器关闭否则等待永远不会停止。
当积压数超过backlog的设置值时，高峰时间大量的云控请求就会触发服务端的502报警。
为了验证这一结论，在测试服务器上修改php-fpm.conf文件中的配置进行一个简单测试。
修改php-fpm.conf的相关配置如下：
listen.backlog = 8 pm = dynamic pm.max_children = 8 pm.min_spare_servers = 2 pm.max_spare_servers = 4
重启php-fpm，客户端发送多于16个请求，每个请求脚本都sleep 10s。采用http_load进行压测，结果如下：
21 fetches, 25 max parallel, 18044 bytes, in 30.0058 seconds
859.238 mean bytes/connection
0.699864 fetches/sec, 601.35 bytes/sec
msecs/connect: 0.472571 mean, 0.637 max, 0.229 min
msecs/first-response: 17094.7 mean, 22743.7 max, 10002.3 min
5 bad byte counts
HTTP response codes:
code 200 – 16
code 502 – 5
从压测结果可以看到，php-fpm能处理的最大请求数应为16，超出这个值的请求会报502错误。
2、php脚本执行超时
在php.ini和php-fpm.conf中分别有这样两个配置项：max_execution_time和request_terminate_timeout。
文档中对其注释如下:;
The timeout for serving a single request after which the worker process will
; be killed. This option should be used when the 'max_execution_time' ini option
; does not stop script execution for some reason. A value of '0' means 'off'.
; Available units: s(econds)(default), m(inutes), h(ours), or d(ays)
; Default Value: 0
;request_terminate_timeout = 0
这两项都是用来配置一个php脚本的最大执行时间的，默认为0s。
当超过这个时间时，php-fpm不仅会终止脚本的执行，还会终止执行脚本的worker进程。
当Nginx会发现与自己通信的socket连接断掉了，以为上游服务器挂了，于是返回给客户端502错误。
修改php-fpm.conf配置如下：
request_terminate_timeout = 10
重启php-fpm，写一个php脚本，sleep 20s。打开浏览器访问测试页面，执行该php脚本验证一下，结果如下图：
由于php脚本执行时间超过配置规定时间，进程被异常终止，所以nginx返回502，验证了上面的结论。
如何避免502
如果服务器并发量非常大，那只能先增加机器，然后按以下方式优化会取得更好效果;但如果并发不大却出现502，一般都可以归结为上述两个原因，php-fpm进程数不够用和php脚本执行超时。
1、增加php-fpm进程数
使用 netstat -napo | grep "php-fpm" | wc -l 查看一下当前fastcgi进程个数。
如果个数接近 php-fpm.conf里配置的pm.max_children上限，就需要调高进程数。
因为max_children设置的较小，那么fastcgi就会“很累”，处理速度也很慢，等待的时间也较长。
但设置max_children也会受到机器资源的限制，因此也并不能无限增加，增大进程数，内存占用也会相应增大。
正常情况下每个php-fpm进程所耗费的内存在20M左右，因此我们线上服务器的配置基本上是最佳的。
2、调整request_terminate_timeout
request_terminate_timeout可以根据服务器的性能进行设定，一般来说性能越好你可以设置越高。
在我们的线上服务器建议直接使用默认值0s就可以了，这样能够避免php进程被异常终止而导致502错误。
可以看到，增加php-fpm进程数和调整request_terminate_timeout均属于配置问题。
在我们的线上环境，相关配置基本上已达到最优，此时要避免502最最重要的还是要控制好程序中的超时。
curl、file_get_contents等函数都要设置超时时间，mysql慢查询请求也要尽量避免。
总结一下
1、nginx出现502错误一般都是后端的php-fpm出问题引起的。
2、pm.max_children不能无限增加，要视机器资源而定。
3、php-fpm.conf中request_terminate_timeout最好采用默认值。
4、大量的慢请求往往才是502的罪魁祸首，所以请一定要管好你程序中的超时。
