502错误、504错误、499错误和500错误

首先看一下概念:

  • 502:作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
  • 503:由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的,并且将在一段时间以后恢复。如果能够预计延迟时间,那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息,那么客户端应当以处理500响应的方式处理它。  注意:503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。
  • 504:作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。  注意:某些代理服务器在DNS查询超时时会返回400或者500错误。

通俗的来说,nginx作为一个代理服务器,将请求转发到其他服务器或者php-cgi来处理,当nginx收到了无法理解的响应时,就返回502。当nginx超过自己配置的超时时间还没有收到请求时,就返回504错误。

502

上面说到nginx收到了无法理解的响应,什么是无法理解的响应呢?

  • nginx无法与php-fpm进行连接。
  • nginx在连接php-fpm一段时间后发现与php-fpm的连接被断开。

那么什么时候会出现上面的情况呢?

  • php-fpm没有启动,nginx无法将请求交给php-fpm
  • php-fpm运行脚本超时,php-fpm终止了脚本的执行和执行脚本的Worker进程,nginx发现自己与php-fpm的连接断开。

我们逐一实验上述的情况:

php-fpm没有启动

我们关闭php-fpm。

[root@localhost ~]# service php-fpm stop
Stopping php-fpm:                                          [  OK  ]

刷新页面,发现返回502错误:

 

 

nginx的error_log:

2016/11/06 11:03:01 [error] 3860#0: *37 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: _, request: "GET /www/muke/index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "127.0.0.1"
php-fpm请求超时

我们首先将php-fpm.conf中的max_terminate_request改成5s:

request_terminate_timeout = 5

在php脚本中添加如下语句:sleep(20);刷新页面,发现返回502错误:

 

 

查看php-fpm的error_log,有如下日志:

[06-Nov-2016 12:26:07] WARNING: [pool www] child 6669, script '/usr/share/nginx/html/www/muke/index.php' (request: "GET /www/muke/index.php") execution timed out (5.482902 sec), terminating
[06-Nov-2016 12:26:07] WARNING: [pool www] child 6669 exited on signal 15 (SIGTERM) after 647.401329 seconds from start
[06-Nov-2016 12:26:07] NOTICE: [pool www] child 6774 started

查看nginx的error_log,有如下日志:

2016/11/06 12:26:07 [error] 6228#0: *46 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: _, request: "GET /www/muke/index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "127.0.0.1"
php-fpm max_children

另外,关于网上说的适当增加max_children参数可能会解决502的问题,我没有实验出来,但是说一下我的实验过程:

关于502与max_children之间的关系,有这样的说法:

max_children最大子进程数,在高并发请求下,达到php-fpm最大响应数,后续的请求就会出现502错误的。

首先我很怀疑这样的说法,因为假设php-fpm的max_children设置为10,即有10个worker子进程。那么假设此时同时有10个并发请求都在占用worker进程进行处理,那么这时第11个请求到来时,就直接拒绝这个请求,连一个等待队列都没有吗?

为了证实我的想法,首先修改max_children的选项如下:

pm.max_children = 1

具体修改过程conf里有详细的说明,pm的值在这里需要为static。

重启php-fpm,查看worker子进程的数量:

[root@localhost ~]# ps aux | grep php-fpm
root       7596  0.0  0.1 245812  3808 ?        Ss   14:10   0:00 php-fpm: master process (/etc/php-fpm.conf)
apache     7597  0.0  0.3 245844  6120 ?        S    14:10   0:00 php-fpm: pool www    

确实变为了一个。

为了增加实验效果,在php文件中增加:

sleep(20);

此时同时打开三个页面,同时发3个请求。如果按照上面的说法,只有一个请求被worker进程处理,其余2个请求因为没有多余的worker处理而被拒绝,返回502。但是实验的结果并不是如此,三个页面最终都返回了http code 200。说明是有一个等待队列存在的。那么这个等待队列是什么呢?

在网上搜寻了一段时间,发现有如下的想法:

当backlog队列满了,会出现502错误

什么是backlog队列呢?
首先我们使用ss命令,观察当前活跃的套接字:

[root@localhost ~]# ss -ln
State       Recv-Q Send-Q                                              Local Address:Port                                                Peer Address:Port 
LISTEN      0      128                                                     127.0.0.1:6942                                                           *:*     
LISTEN      0      128                                                             *:56517                                                          *:*     
LISTEN      0      128                                                     127.0.0.1:9000                                                           *:*     
LISTEN      0      50                                                              *:3306                                                           *:*     
LISTEN      0      128                                                     127.0.0.1:63342                                                          *:*     
LISTEN      0      128                                                            :::111                                                           :::*     
LISTEN      0      128                                                             *:111                                                            *:*     
LISTEN      0      128                                                             *:80                                                             *:*     
LISTEN      0      128                                                            :::60816                                                         :::*     
LISTEN      0      128                                                            :::22                                                            :::*     
LISTEN      0      128                                                             *:22                                                             *:*     
LISTEN      0      128                                                     127.0.0.1:631                                                            *:*     
LISTEN      0      128                                                           ::1:631                                                           :::*     
LISTEN      0      100                                                           ::1:25                                                            :::*     
LISTEN      0      100                                                     127.0.0.1:25                                                             *:*    

我们观察127.0.0.1:9000这一行:

LISTEN      0      128                                                     127.0.0.1:9000                                                           *:*     

关注Recv-QSend-Q这两个字段。啥意思呢?我也不懂。参考TCP queue 的一些问题的说法:

  • LISTEN 状态: Recv-Q 表示的当前等待服务端调用 accept 完成三次握手的 listen backlog 数值,也就是说,当客户端通过 connect() 去连接正在 listen() 的服务端时,这些连接会一直处于这个 queue 里面直到被服务端 accept();Send-Q 表示的则是最大的 listen backlog 数值,这就就是上面提到的 min(backlog, somaxconn) 的值。
  • 其余状态: 非 LISTEN 状态之前理解的没有问题。Recv-Q 表示 receive queue 中的 bytes 数量;Send-Q 表示 send queue 中的 bytes 数值。

其余的细节查看刚才贴出的参考链接。

于是,将php-fpm的conf中的listen.backlog修改为1:

; Set listen(2) backlog. A value of '-1' means unlimited.
; Default Value: -1
listen.backlog = 1

重启php-fpm,查看修改结果:

[root@localhost ~]# ss -ln | grep 9000
LISTEN     0      1                 127.0.0.1:9000                     *:*     

修改成功。php-fpm目前的backlog为1,即php-fpm的等待队列里只能有一个请求在等待worker进程进行处理。

同时发三个请求,查看结果:
结果为:三个请求又最终成功返回http code 200。与我猜想的不符和啊,不是backlog为1吗?
最后发现下面一段话:

当 queue 满了之后,服务器并不会按照理论所述,不再对 SYN 进行应答,返回 ETIMEDOUT。根据这篇文档的描述,实际情况并非如此,服务器会随机的忽略收到的 SYN,建立起来的连接数可以无限的增加,只不过客户端会遇到延时以及超时的情况。

再实验一次,同时运行ss -ln

[root@localhost ~]# ss -ln | grep 9000
LISTEN     2      1                 127.0.0.1:9000                     *:*     

过一段时间后:

[root@localhost ~]# ss -ln | grep 9000
LISTEN     1      1                 127.0.0.1:9000                     *:*     

发现Recv-Q字段的值为2,过一段时间变为1,说明php-fpm并没有拒绝后两次请求。

那么最终的结论是:适当增加max_children还是有用的,这样的话php-fpm能同时处理的请求增加,客户端的延迟等待时间也会相应的减小。

fastcgi_buffer系列

还有种说法是当nginx的fastcgi的buffer设置过小时,也会有502。

fastcgi_buffer_size 1k;
fastcgi_buffers 2 1k;
fastcgi_busy_buffers_size 1k;

这个自己也没有实验出来,自己理解的是如果buffer开启过小的话,work进程需要将response body中在buffer放不下的部分放到磁盘上,降低了效率,work进程的响应时间会变慢,效率降低。假如此时有高并发的请求,可能会出现502错误。

504

504即nginx超过了自己设置的超时时间,不等待php-fpm的返回结果,直接给客户端返回504错误。但是此时php-fpm依然还在处理请求(在没有超出自己的超时时间的情况下)。

这里有三个相关的配置:

  • fastcgi_connect_timeout 300;
    指定连接到后端FastCGI的超时时间。
  • fastcgi_send_timeout 300;
    向FastCGI传送请求的超时时间,这个值是指已经完成两次握手后向FastCGI传送请求的超时时间。
  • fastcgi_read_timeout 300;
    接收FastCGI应答的超时时间,这个值是指已经完成两次握手后接收FastCGI应答的超时时间。

这里我们将fastcgi_read_timeout设置为1s,后端还是延迟20s,观测效果:
screenshot

nginx返回504错误。

499定义

499, Client Closed Request, 客户端主动断开连接。

是指一次http请求在客户端指定的时间内没有返回响应,此时,客户端会主动断开连接,此时表象为客户端无响应返回,而nginx的日志中会status code 为499。

此状态码在浏览器请求时几乎不可见,因为浏览器默认的超时时间会很长。多见于服务之间的调用,在业务架构中常常会分层设计,拆分为不同的子系统或者微服务,这样系统之间就会常常通过http方式来请求,并且会设置每次请求的超时时间,当请求在请求时间内所调用的上游服务无返回,则会主动关闭连接,上游服务日志中会记录一条499。

500定义

500, Internal Server Error , 服务器内部错误,服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。

日常开发中500错误几乎都是由于php脚本语法出现错误导致php-fpm无法正常执行。

posted @ 2020-04-20 14:51  泥土里的绽放  阅读(1279)  评论(0编辑  收藏  举报