业务量剧增后服务器常见返回码总结

Nginx返回码 500（Internal Server Error  内部服务器错误）

服务器内部错误，也就是服务器遇到意外状况，而没法执行请求。发生错误，通常的几种状况：

• Web项目中出现异常，项目应用中有Bug
• 访问量大的时候，因为系统资源限制，而不能打开过多的文件句柄

定位思路：

1.查看access.log

[root@prod-nginx-01 ~]# cat /var/log/nginx/access.log | grep --color 'HTTP/1.1" 500'
183.131.0.1 - - [21/Apr/2018:17:40:11 +0800] "POST /checkupdate HTTP/1.1" 500 158 "-" "okhttp/3.6.0" "-" 10.016

2.判断是不是too many open files

• 打开/etc/security/limits.conf
• 修改 limits.conf文件，加上下面两句命令

　　* soft nofile 65535　　　　* hard nofile 65535

• 打开/usr/local/nginx/conf/nginx.conf，在worker_processes的下面增长一行配置 worker_rlimit_nofile 65535;

• 从新启动nginx

#查看系统默认的最大文件句柄数，系统默认是1024
[root@prod-nginx-01 ~]# ulimit -n
655350
#查看当前进程打开了多少句柄数,第一列是打开的进程数，第二列是进程ID
[root@prod-nginx-01 ~]# lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more | head -5
   4010 2911
   3860 2912
   3774 2913
   3517 2910
    137 13209

　　

Nginx返回码 499（client has closed connection 客户端主动关闭）

官方解释：

ngx_string(ngx_http_error_495_page), /* 495, https certificate error*/
ngx_string(ngx_http_error_496_page), /* 496, https no certificate */
ngx_string(ngx_http_error_497_page), /* 497, http to https */
ngx_string(ngx_http_error_404_page), /* 498, canceled */
ngx_null_string,                    /* 499, client has closed connection */

499，客户端关闭链接，这个状态码并非http协议中定义的status code，而是nginx本身定义的一个状态码。

• 因为服务器处理请求较多，客户端在有效时间内没有获得答复，主动关闭了链接。
• 有人说把时间设置长一些或者使用proxy_ignore_client_abort on（让代理服务端不要主动关闭客户端的链接）。
• 可是这样也有必定的风险，会拖垮服务器。发生这个错误，若是服务器CPU和内存不算过高，通常是数据库和程序的问题，数据库处理较慢或者程序线程较低。
• 结合状况调整，好比读写分离或者程序线程数调高。

client发送请求后，若是在规定的时间内（假设超时时间为500ms）没有拿到nginx给的响应，则认为此次请求超时，会主动结束，这个时候nginx的access_log就会打印499状态码。

其实这个时候，server端有可能还在处理请求，只不过client断掉了链接，所以处理结果也没法返回给客户端。

499若是比较多的话，可能会引发服务雪崩。好比说，client一直在发起请求，客户端由于某些缘由处理慢了，没有在规定时间内返回数据，client认为请求失败，中断此次请求，而后再从新发起请求。

这样不断的重复，服务端的请求愈来愈多，机器负载变大，请求处理愈来愈慢，没有办法响应任何请求。

我试图定位了一下咱们几个项目中的499出现几率，目前统计的几个接口的出现频率。

interface_1 十万分之五
interface_2 万分之一
interface_3 千分之一
interface_4 千分之一
interface_5 千分之一

相较之下，与运维探讨得出目前的错误率仍是能够接收的，可暂不处理。
另外为什么0秒返回499 这个不是很好定位确认，网上也没有合理的实践经验，若是要定位须要在较低的几率中抓到出错的请求，具体分析。
结论：可先观察一段时间，若是一直较低几率出现，可暂不处理。

 

Http返回码 400（Bad Request 错误请求） 

一、语义有误，当前请求没法被服务器理解。除非进行修改，不然客户端不该该重复提交这个请求。 

二、请求参数有误。

如将本来Post请求的json格式的body换成binary格式就会返回这个错误码及下面的返回结果。

{
    "timestamp": 1524322831388,
    "status": 400,
    "error": "Bad Request",
    "exception": "org.springframework.http.converter.HttpMessageNotReadableException",
    "message": "Required request body is missing: public com.test.http.model.common.Object com.test.http.controller.TestController.forTest(Object,javax.servlet.http.HttpServletRequest)",
    "path": "/interface"
}

 

Http返回码 405（Method Not Allowed 不被容许的请求方法）

请求行中指定的请求方法不能被用于请求相应的资源。

如本来Post的请求，你换成了Get的请求方式，就会返回这个错误码及下面的返回结果。

{
    "timestamp": 1524322516567,
    "status": 405,
    "error": "Method Not Allowed",
    "exception": "org.springframework.web.HttpRequestMethodNotSupportedException",
    "message": "Request method 'GET' not supported",
    "path": "/interface"
}

 

参考文章：

http://www.javashuo.com/article/p-whqjwjni-gd.html

https://blog.csdn.net/qq_35621350/article/details/71056970

https://www.linuxidc.com/Linux/2017-01/140055.htm