当前位置: 代码迷 >> 综合 >> recv() failed (104: Connection reset by peer) while reading response header from upstream问题的解决
  详细解决方案

recv() failed (104: Connection reset by peer) while reading response header from upstream问题的解决

热度:39   发布时间:2023-11-25 02:19:38.0

背景

recv() failed (104: Connection reset by peer) while reading response header from upstream问题很显然是 nginx 与php-fpm 间的通信出现了问题,通常是php-fpm由于超时等原因终止导致nginx未收到有效回应。
我这次写这个问题比较局限,是在phalcon框架下发现偶发性的异常问题,且是在线上环境发现的,因此对此问题进行了排查。最终原因是由于内存导致的,因为我怀疑了很多原因,但都不是根源所在,也在网上找到很多类似的问题,但查到的解决方案都不是我的问题根源,所以这篇文章主要是做个记录,本片文章可能对大多数人没有参考意义。

问题发现

之前交接的一个比较老的项目使用的phalcon框架,phalcon是一个与yaf类似的,基于php扩展的注重性能的框架(官网传送门)。由于新加了一些小功能,开发完成后在提供的测试环境进行测试时,发现会出现偶发的502错误,且没有任何规律,我观察了nginx的error_log、php的error_log、php-fpm的error_log,没有找到有效的错误信息。

nginx日志:
2019/03/22 20:17:17 [error] 16436#0: *573 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxxxx, server: xxxxx, request: “GET /article HTTP/1.1”, upstream: “fastcgi://unix:/dev/shm/php-fpm.sock:”, host: “xxxxx”, referrer: “xxxxx”
php-fpm日志:
[23-Mar-2019 17:36:25] WARNING: [pool www] child 1843 exited on signal 9 (SIGKILL) after 248.595491 seconds from start

从日志中能够获取到的只是一个标准的反馈,nginx告诉我们没有收到反馈,php-fpm告诉我们进程中断了,但没有人告诉我们为什么。

最初我怀疑的是数据大或者逻辑错误导致php-fpm进程执行时间超时,但慢日志并没有记录,且发现请求在1s+就直接502了,所以确定并不是执行超时导致。

另外注意到我本地环境并没有发现此问题,所以我怀疑是测试环境的硬件配置或nginx/php的设置参数有问题,导致phalcon框架的异常,于是我到线上也进行了验证,结果发现。。。线上竟然也有这个问题,不过很少出现,没有测试环境这么频繁,我就纳闷这个问题一直都没人反馈吗??出于职业道德,不得不给别人擦屁股。

问题处理

于是我查找有没有使用phalcon框架的人也遇到过相同问题并已经有了解决方案,然后我找到几种看似可能的原因:

1、phalcon扩展和opcache扩展的不兼容导致

这个原因看着有点道理,毕竟都是php扩展,且phalcon扩展我并不确定他已被广泛应用并经过了大众的检验。说实话我是这次交接这个项目后才听说这个框架的,然后到官网看了看文档,觉得这个框架也不错,发展的也可以,但可能多少存在一些问题。
于是我暂时关闭了opache扩展,然后再次进行试验,结果问题依旧存在,pass

2、phalcon扩展编译时操作系统位数与实际不一致

在这里插入图片描述
在这里插入图片描述
??原文地址


??原文地址

这个哥们的问题和我的如出一辙啊,而且线上和测试环境都是交接时运维直接镜像部署的,phalcon扩展到底谁编译安装的,安装的对不对确实没人保证也无法查证啊。正在我以为找到了原因,准备重新编译一遍试试时,我注意到我之前在本地搭建环境编译安装时没有选择操作系统位数,并且这个问题是2013年解答的,时间跨度有点大,于是我又到官网确认了下,linux系统的扩展安装没有提及操作系统位数,况且编译的位数不对也不应该偶发,应该会始终异常才对。
显然这个原因也不是我想要的。

3、phalcon框架本身原因

在这里插入图片描述
文档有这样一段描述,“phalcon可能会使您的某些web服务器进程崩溃”。那如果是这样的话,就无解了啊。。

于是我觉得我应该脱离phalcon框架,从php本身去思考问题,说不定问题并不想我想的那么复杂,只是一个小问题。

确实,我起初所有的猜测都是以phalcon扩展为出发点的,不知道怎么的注意力就全被拉到了phalcon上。

问题解决

于是我查阅了可能php-fpm出现recv() failed (104: Connection reset by peer) while reading response header from upstream问题的原因,两大主要原因就是执行超时进程终止和可用内存不够进程终止。
执行超时我之前已经检查过了,php.ini和php-fpm.conf中对php-fpm和cli的超时时间都远超我业务实际执行时间,不存在超时的问题,且请求返回的时间就一两秒。
所以内存成了主要怀疑对象。确实我之前一直没有核对过这个测试服务器的配置,因为一般都会给到2c2g左右的配置,况且只有我一个人在访问,应该不存在性能问题。但我检查机器配置发现这个机器是1c1g,且每次出问题时mem和swap的可用大小都很小了,寥寥可数,那问题就在这了。
于是再次检查php配置,发现php-fpm的配置

pm = static
pm.max_children = 64

以static模式运行64个php-fpm进程,不太适合这个机器的实际配置情况,但应该不至于挂啊,观察php-fpm进程,确实在执行多次请求,且查询大量数据时,很多php-fpm进程占用了大概15%以上的内存,想起phalcon对分页的处理貌似是使用整个orm对象结果集来构造分页数据对象(具体的暂时没有仔细研究),加之数据量确实很大,可能存在消耗内存的情况,如果存在内存泄漏,那这个情况会更凸显。

这样分析较为符合目前偶发的异常问题,另外就这台机器的配置而言,dynamic模式更加适合,进程数也不适合那么多,目前的设置明显也不符合实际,哪怕这不是问题原因肯定也需要优化,内存泄漏直接用pm.max_requests来处理,如果存在的话会得到缓解。

于是我修改了php-fpm的配置:

pm = dynamic
pm.max_children = 15
pm.start_servers = 8
pm.min_spare_servers = 6
pm.max_spare_servers = 15
pm.max_requests = 500

貌似接近默认配置,不过我觉得这样比之前要合适的多。

然后重启php-fpm再次验证一下异常问题是否也得到解决。

在几百次请求后,问题确实没在出现,机器内存也没在像之前一样出现低于1000k的情况。

那么问题到这里结束,之后再去温习一下php-fpm的相关配置,然后深入研究一下对问题进行确认。

  相关解决方案