業務量劇增後服務器常見返回碼總結

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