nginx日誌中出現499狀態碼

參考鏈接：

https://www.jianshu.com/p/aa5a06fef39c  聊聊nginx報錯499問題

https://www.iteye.com/blog/kingj-1457384  proxy_ignore_client_abort on

https://blog.51cto.com/yucanghai/1713803 服務器排障 之 nginx 499 錯誤的解決

https://www.linuxidc.com/Linux/2017-01/140055.htmNginx 499錯誤解決方法

 

 

nginx的access.log中出現大量的499返回碼：

 

網上關於499狀態碼的解釋：

499 CLIENT CLOSED REQUEST

A non-standard status code introduced by nginx for the case when a client closes the connection while nginx is processing the request.

 

服務器返回http頭之前，客戶端就提前關閉了http連接，常見於後臺接口處理時間比較長，而前端請求又自帶有超時時間。

很有可能是因爲服務器端處理的時間過長，客戶端“不耐煩”了

 

分析：

繼續排查服務器端時間過長的問題

 

可能問題：

1、後臺python程序處理請求時間過長

2、mysql慢查詢

通過查看監控：

1、cpu（top）與內存（free -h）的使用，在正常範圍內；

2、後臺程序都ok

3、MySQL存在慢查詢，因爲執行select語句卡死

 

 

使用命令show processlist命令查看MySQl中的進程，發現有Waiting for table metadata lock，初步判定因爲某個操作阻塞，導致後續操作無法執行，即死鎖問題。

 

可採取如下方法先規避掉：手工將該表logupload_task中的數據清掉，步驟如下：

1、備份數據庫數據（參考 mysql操作）
備份：backup.sh  
格式：mysqldump -h主機名  -P端口 -u用戶名 -p密碼 –database 數據庫名 > 文件名.sql  
樣例：mysqldump -h 127.0.0.1 -P 3307 -u ctdidb --password=P@ssw0rd > backupfile.sql
    
恢復：recover.sh  
格式：mysql -h主機名 -u用戶名 -p密碼 databasename < backupfile.sql
樣例：mysql -h 127.0.0.1 -P 3307 -uctdidb -pP@ssw0rd di_stats < di_stats_bak.sql

2、將操作該表logupload_task的模塊（進程）殺死，再delete清空該表數據，最後啓動殺掉的模塊服務，這個時候服務就ok了。

但這樣處理只是暫時規避了，沒從根本上解決問題，還需要提高後端處理邏輯，提高性能。