nginx+apache 502 Bad Gateway 深度思考

502 Bad Gateway是nginx服务器上面经常遇到的问题,但是在网上查找资料的时候,95%的资料都是在讨论nginx+php-fpm的环境下如何如何处理。而我的环境是nginx + apache,为了把这个问题搞清楚,我希望通过这篇文章,能深入的对这个问题的解决思路做一个梳理。

502是nginx返回的错误

所有的502都是nginx返回的,在错误页面也可以看到只有nginx作为标识,没有看到apache。这说明502是在nginx这个环节出现了问题。所以,我们需要来再梳理一下,在nginx+apache这个环境中数据包的处理逻辑:

nginx-httpd-502.fw

如上图,当请求到达nginx时,nginx将请求转发给apache进行处理,当apache将结果返回给nginx时,nginx再将结果展示给访客。但是,如果nginx转发请求之后,迟迟没有收到apache的结果,或者apache返回的结果和nginx预期的结果不对等,就会返回502错误。

那么这里面就包含了两个因素:

  • 1)时间
  • 2)数据

当处理时间超出预期时,可能产生502错误。当nginx得到的数据不符合预期时,也可能产生502错误。那么时间问题是怎么产生的呢?数据问题又是怎么产生的呢?

服务器性能造成的502问题

服务器的性能、配置的参数等,导致在整个请求处理过程中,请求被阻塞,从而导致请求处理时间过长,从而引起服务器假死等问题,其结果之一,就是nginx返回502错误。

机子硬件配置太低

服务器机器的配置确实太差的时候,环境跑起来其实是有点吃力的。服务器的硬件配置影响性能的,主要包括:内存、cpu、宽带、硬盘。

这些其实不必过多的去解释,大家都懂的。但是,这里面需要考虑的是,你的服务器到底配置多大的内存,多高的宽带,cpu多少核才好呢?你要这样去思考:

首先是cpu,它决定了程序运算的速度,并不是核数越多越好,因为一段程序的运行计算只需要那么多资源,多出来的cpu其实是浪费的。同一时间的访客数量运行不同的程序,就会使cpu占用率上升,你最好通过长期监控cpu的占用率,来了解你的当前cpu是否能够支持当前平均访客数量的运算需要,一旦超出某个值,就应该考虑加核。

内存也是同样的道理,内存是程序在执行过程中消耗掉的,当你的访客数上升的时候,内存就会被开销,你也应该长期去监控内存的占用情况,看到每天的峰值达到一个高度的时候,就考虑加内存。

cpu和内存、宽带都要用这种思维去考虑是否机子升级。当你升级到满足最高峰值的时候,502自然就不会出现了。

性能相关的服务器配置参数待优化

当你满足上面的硬件配置之后,就应该考虑一下服务器各个参数的优化。这里指的参数,是指上述nginx apache php mysql redis等他们在内存、IO上面的使用安排。

举一个例子,如果一台服务器内存为512M,系统占用了120M左右,其他一些服务占用了50M左右,现在有300M左右的内存留下来给napmr环境去运行。其中,redis的数据常驻内存,因此最好不要在这台服务器上使用。每一个访客访问某个网页的时候,nginx可能会用10M,apache用20M,php则根据该网页后台程序的逻辑,有可能用到8-32M,而如果这个页面需要连接Mysql进行数据库查询,Mysql又会根据连接和查询数不同,消耗掉可能16-64M的内存,这样算下来,同一时刻,单个访客可能就会消耗60-120M的内存,而你剩下的300M内存,最多也就能撑死5个访客,超过5个人的第6个人,就需要等待,直到前面的处理已经结束,内存被释放出来。(当然,这里仅仅是一个假设的例子)

而在nginx、apache、php的配置文件中,可以对这些消耗进行有限的配置。比如可以配置最大消耗内存,比如php最多允许消耗32M内存,当访客访问的页面php消耗的内存到达这个值的时候,就会在页面中返回错误结果,甚至直接白屏。这样,就可以为其他用户省下内存,第6个人进来时,内存还有,就可以直接打开页面,而无需等待内存释放。

除了内存的控制,服务器的配置参数中还有很多,可以有效对服务器资源进行分配。具体的这些配置,需要你去搜索nginx、apache、php相关的配置教程。

请求阻塞造成的502问题

在我们看到502的时候,所能了解到的,仅仅是nginx无法为你提供服务,返回的错误,而不知道后面具体是哪一个位置出了问题。网上大部分材料都说是php-fpm的配置问题,但实际上,问题可能会出现在php-fpm的后面环节。

我们来看一个情况:

nginx-httpd-502-2.fw

上图中表示了一种情况,当php程序(运行时,而不是指代码执行)运行过程中,服务器突然内存占尽导致php进程崩溃,这个时候,php不会返回apache任何数据,而是apache监听到程序执行异常,这种异常让apache决定返回一个异常,而nginx在得到这个异常时,由于与预期得到的结果不同,所以返回了502.在这种情况中,问题并不是出现在apache这个环节,而是php这个环节。类似的,如果请求依赖于其他应用程序,这些应用程序突然崩溃的时候,也有可能返回502.

因此,要解决这个问题实在比较难,需要对整个运行机制做深入的监控,才能准确的把握问题的根源,才能定位解决问题。

一般这种监控可以通过以下途径去做:

  • 1)日志
  • 2)综合数据
  • 3)逻辑分析

日志是比较靠谱的,例如上面这个案例中,日志可以这么去找。nginx的访问日志中记录了这条访问,再从apache中找到同样一条访问,再去分析php错误日志,找出最后几条错误是否是这次访问产生的。这样顺藤摸瓜,就可以大致定位错误引起的原因,在通过该原因具体分析引起这个错误的更深层次的原因,最终找到症结。

但是,为了提升性能,大多数服务器中没有保存日志,或者有些日志记录并不能帮助我们找到根源。这个时候就要你拥有数据分析和逻辑分析的能力,前提是你对这一整套的运行机制比较了解。通过服务器提供商提供的一些数据,服务器本身反馈的一些数据(如top free等命令得到的数据),以及日志记录,再按照请求运行的逻辑分析问题可能出现的位置,并且每个地方进行排查,一点一点去验证。

好了,本文主要是梳理了遇到502的解决思路,是提纲挈领式的提供思维方式。它不仅要求你能够完成服务器配置,而且要求你对服务器运行机制有更深入的了解,这或许是学习的一种有效方式。

2016-01-28