陶利军老师写书不易，就不公布啦，谁看到了，就算运气好吧

无论是502还是504错误，都有可能是Nginx的相关错误，也有可能是后端服务器发生故障

如果是php-fpm的故障，造成这种故障的原因可能是：php-cgi进程数不够用，php执行时间长或者是php-cgi进程死掉，以及nginx端FastCGI缓存使用情况（如果使用的代理，还要注意代理缓存的使用情况）。分析如下：

1）首先需要确定的是后端服务器启动没有，当然在这里就是php-fpm进程启动没有。如果该进程没有启动，或者由于某种原因出错而退出，那么得到的访问结果肯定是502 Bad Gateway

    ps -ef | grep php-fpm  

    注意查看结果中的进程池啊，呵呵

2）其次是确定php-fpm的worker进程是否够用，如果不够用，对于访问者来说就如同后台服务没有开启一样：

  计算开启的worker进程数目：

    ps -ef | grep php-fpm | grep -v “master” | grep -v grep | wc -l

   这里将master主进程，和grep进程过滤掉了

 然后计算被使用的worker进程（正在处理请求的进程）：

   netstat -anp | grep “php-fpm” | wc -l

 得到的值应该再去掉grep进程，LISTEN监听，和另一个php-frm.conf，而LISTEN的个数要看进程池的数量。

或者 netstat -anp | grep "php-fpm" | grep -v grep | grep -v "LISTEN" | wc -l

如果这两个值相近，那可以考虑增加worker进程的数量

3）FastCGI缓冲（buffer）或是代理的缓存情况。

    在FastCG模块中，与缓存有关的指令有以下两条：

    fastcgi_buffer_size    4k；

    fastcgi_buffers   16    4k；

   因为第一条指令的设置依赖于操作系统对内存页面的设置，所以它可以从操作系统查出来

   #getconf  PAGESIZE 

   得到4096，这个数值单位是字节（byte），也就是4KB

   第二条指令的参数指定将使用多大的缓存区来读取从FastCGI进程到来的应答头，这个值由这两条命令的结果16*4KB=64KB决定。这意味着所有的FastCGI返回的应答，Nginx将超过64KB的部分写入磁盘，而64KB以内的部分写入内存。

   如果你设置的等待时间太短，机器又太忙，势必会造成502问题.

  如果使用的是代理模块，那么会是以下的设置：

  proxy_buffer_size  16k；

  proxy_buffers  4  16k；

 上面两条的解释方法等同于上面的FastCGI缓存的解释。

 4）php执行时间长

  在FastCGI模块中，与时间设置有关的指令有三条，举个极端的例子来说明：

假如你将fastcgi_send_timeout的值设为1秒，而你的php脚本执行却需要5秒，那么肯定会报502了。

   因此需要根据实际情况来调整以下三条指令：

   fastcgi_connect_timeout  60；

   fastcgi_send_timeout  60；

   fastcgi_read_timeout  60；

  不同的网站应用的内容页不同，要求也不同，因此只能根据应用情况适当的调整这三条指令。

 如果是代理模块，那么相关设置如下：

 proxy_connect_timeout  60；

 proxy_send_timeout  60；

 proxy_read_timeout  60；

 fail_timeout  30;

 以上代理模块命令的意思和FastCGI模块的相似。其中最后一条是upstream模块的指令，如果使用了负载均衡，那么参考该指令的使用设置。

5）经常查看php-fpm的日志，特别是在出问题的时候，要将日志的级别调整为“DEBUG”级别，以便了解问题的出处。有关日志部分，请参考相关章节（我还没看，呵呵）。