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

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

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 错误请求)

1、语义有误,当前请求无法被服务器理解。除非进行修改,否则客户端不应该重复提交这个请求。

2、请求参数有误。

如将原本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"
}

参考文章:

https://www.cnblogs.com/kevingrace/p/7205623.html

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

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


目录
相关文章
|
3天前
|
Oracle 数据库 UED
后台查询接口影响响应时间最大的因素:用空间换时间的优缺点及解决方案
1.当数据库的一个表记录很多显然查询数据很慢。 2.当数据库的一个表记录不大,但是数据很大也可能很慢。 我们的一个用户表中一个building很大,当查询100条数据就会把服务器的内存搞爆掉。 当然查询时要查询筛选有用字段,不可以直接把记录的所有字段都查拆来。这样能减少内存消耗和提高查询速度。 3.在经常查询字段上建立索引。据说oracle上用索查询和不用索引查询在超多记录的情况下相差1000倍。 4.若出现嵌套查询显然会大大增加相应查询时间。要先预处理用管道操作把能合并的查询合并到一个查询中,然后生成map,然后再处理。这是标准的用空间换时间的方案。
28 7
|
9月前
|
定位技术
后端一次性返回几百万条数据怎样处理
后端一次性返回几百万条数据怎样处理
|
10月前
|
存储 Cloud Native 前端开发
12-如何抗住双11一天几十亿的订单量?JVM该如何设置内存?
通过之前相关JVM的基础知识学习我们可以结合一些实际生产案例来进行结合巩固和说明,我们在上线一个生产系统的时候,针对预估的并发压力,到底应该如何合理的给出一个未经过调优的比较合理的初始值。 另外我们会分析各种参数在设置的时候有哪些考虑的点,Java堆内存到底需要多大?新生代和老年代的内存分别需要多大?永久代和虚拟机栈分别需要多大?这些我们都会结合案例来一步一步的分析。 注意:JVM参数到底该如何设置,一定是根据不同的业务系统具体的一些场景来调整的,不是说有一个通用的配置和模板,照着设就没问题了,这个思路是肯定不对的,一定要结合案例和业务场景来分析。
102 0
12-如何抗住双11一天几十亿的订单量?JVM该如何设置内存?
|
10月前
|
存储 开发框架 负载均衡
限流的非常规用途 - 缓解抢购压力
限流的非常规用途 - 缓解抢购压力
74 0
|
SQL 存储 自然语言处理
最近搞了个毫秒级返回百亿数据!我都做了啥! 上
最近搞了个毫秒级返回百亿数据!我都做了啥! 上
|
canal otter Oracle
最近搞了个毫秒级返回百亿数据!我都做了啥! 下
最近搞了个毫秒级返回百亿数据!我都做了啥! 下
|
SQL 运维 监控
redis瞬时查询返回量过多导致出口流量打满,影响系统整体响应时间
redis瞬时查询返回量过多导致出口流量打满,影响系统整体响应时间
355 0
redis瞬时查询返回量过多导致出口流量打满,影响系统整体响应时间
|
存储 运维 负载均衡
邓荣伟:稳定支撑每秒百万笔支付请求,支付宝数据库架构的过去、现在与未来
8 月 10 日,2022 OceanBase 年度发布会在京沪深三地同时召开,支付宝资深数据库专家邓荣伟在会上分享了《从“小”到“大”,支付宝分布式升级之路》的主题演讲,为我们带来了支付宝的架构演进以及上线 OceanBase 的故事。
388 0
邓荣伟:稳定支撑每秒百万笔支付请求,支付宝数据库架构的过去、现在与未来
|
Web App开发 SQL 监控
如何做“健康码”的性能压测
随着无线设备的普及和 5G 的大力建设,越来越多的线上系统、小程序成为了人们生活中必不可少的工具。对于这些工具,都会面对一个问题:系统能承受多少用户同时访问,面对突发的流量洪峰,能否保证系统无故障稳定运行?本文将解答这个问题并进行解说。
如何做“健康码”的性能压测
|
运维 监控 Java
日均千万级消息规模,深捷旅使用函数计算释放运维压力
函数计算可以监听多种数据源,通过监控处理业务量的变化,快速进行自适应的扩缩容操作, 通过毫秒级的扩容,可以获得线性增长的业务处理能力。
1768 1
日均千万级消息规模,深捷旅使用函数计算释放运维压力