一些PHP进程的故障分析以及处理思路整理！

  对于运维而言，我们必须要做到的一点时能够快速的定位到问题的点，当接到报障时在心里就可以根据故障的描述经行问题分类，而精准的问题分类也是经行下一步分析的处理的基础所在。

  当然，故障从用户反馈时再到解决完成这个过程是很久的，如果我们自身熟悉业务的情况下，那么我们可以很快的回想起整个业务的架构，但如果对于业务不熟悉，那么我们还得去找架构图等，并且还有确保拿到的架构图是最新的（根据业务需求或许不定期会增加服务器承载业务的稳定性，而在架构图中不一定更新）。时间一分一秒的过去，而我们对于故障可能还是很蒙的状态。或许我们可以找到研发部门的同时跟你去慢慢排查，但是对于用户而言是不会等你的，所以只能看着用户的流失，那么我相信公司是不允许出现这种情况的。

那么一般的故障问题其实跟性能问题是息息相关但又有不同之处。比如性能可以体现为吞吐低和高延迟，那么如果说达到一定的量或者是突破极限后基本就会成为故障。

那么我将我遇到的一些问题整理下来，其实大部分的php故障都会反应在用户端，用户看到的可能是HTTP的几种错误码的反馈，也有可能是业务卡顿等。如果你的业务没有进行异常处理，常见的错误码一般为以下几种：

502错误：这个错误一般是PHP执行的太久，导致超过了参数request_ternubate_timeout（请求几次超时）和max_execution_time（请求最大时间）所设定的参数，导致PHP工作进程被终止，无法为fastcgi接口提供信息的传输，那么如果PHP的错误日志中出现了SIGxxxxx时，即有可能会出现这个情况。那么原因可能回事后端存储或者调用外部连接反应很慢，或者是服务挂了，导致php一直在等待，达到了自己结束等待的条件。

502错误的一般处理方法：如果是请求超时时间配置不合理，则需要延长超时时间。另一方法则是从后端入手，找到关键的点，比如配合数据库运维分析慢查询，死锁，执行中的sql等。然后处理解决。

503错误：一般出现这个错误的时候多半是整个服务不可用了。这类错误一般是Web服务器（如nginx）这一层还活着，但是无法响应用户的请求。

503错误一般处理方法：重点分析Nginx是否存活，端口是否存活，Nginx工作的饱和度。

504错误：504则表示处理时长过高 网关超时，可能是应为请求量的突增，导致php的负载过高，无法为请求及时分配工作进程，或者是达到了连接数的限制，某些进程达到了瓶颈。导致系统性能下降；那么导致504错误的多半是Nginx配置文件中的超时设置：如

Fastcgi_connect_timeout(fastcgi连接超时)，fastcgi_send_timeout(fastcgi发送超时)，fastcgi_read_timeout(fastcgi读取超时)。Ps：若为tomcat服务或许是upsteam中的fail_timeout参数

  504错误的一般处理方法：如果每个请求的处理时间都是正常的，那么可能是整个php层的硬件资源不够用了，或许需要升级硬件。如果说是某些请求时间长，那么就压找到性能的瓶颈点了（配置文件是否有误，负载是否过大等等）

 

  那么如果是日常正常运行的业务突然变得卡顿，则很有可能是性能问题造成的，很多时候其实是大量的用户请求导致某些组件达到了性能的瓶颈。由PHP的性能问题所引起的故障常见的有以下几种：

PHP进程不存在：可能是由于进程以外挂掉，没有起来，比较常见的场景一般是请求一直在处理达到了我们所设定的最大执行时间，管理进程把工作进程给杀了。

PHP进程本身很慢：其实这种情况并不多，应该会出现在极其复杂的架构业务中。

依赖后端存储慢：这是比较常见的情况，一般为mysql，redis出现故障或者性能问题。