邯郸企业做网站报价,wordpress 禁用所有插件,大丰网站开发,做网站的成本有多少钱首先看一下概念#xff1a;
502#xff1a;作为网关或者代理工作的服务器尝试执行请求时#xff0c;从上游服务器接收到无效的响应。503#xff1a;由于临时的服务器维护或者过载#xff0c;服务器当前无法处理请求。这个状况是临时的#xff0c;并且将在一段时间以后恢…首先看一下概念
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-fpmphp-fpm运行脚本超时php-fpm终止了脚本的执行和执行脚本的Worker进程nginx发现自己与php-fpm的连接断开。
我们逐一实验上述的情况
php-fpm没有启动
我们关闭php-fpm。 [rootlocalhost ~]# service php-fpm stopStopping php-fpm: [ OK ]刷新页面发现返回502错误 image
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.1php-fpm请求超时
我们首先将php-fpm.conf中的 max_terminate_request 改成5s request_terminate_timeout 5在php脚本中添加如下语句 sleep(20);刷新页面发现返回502错误 image
查看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.1php-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子进程的数量 [rootlocalhost ~]# 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命令观察当前活跃的套接字 [rootlocalhost ~]# 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-Q和Send-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查看修改结果 [rootlocalhost ~]# 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 [rootlocalhost ~]# ss -ln | grep 9000
LISTEN 2 1 127.0.0.1:9000 *:*过一段时间后 [rootlocalhost ~]# 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观测效果 nginx返回504错误。
