nginx日志中出现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 username --password=password > backupfile.sql
    
恢复：recover.sh  
格式：mysql -h主机名 -u用户名 -p密码 databasename < backupfile.sql
样例：mysql -h 127.0.0.1 -P 3307 -uusername -pPassword di_stats < di_stats_bak.sql

2、将操作该表logupload_task的模块（进程）杀死，再delete清空该表数据，最后启动杀掉的模块服务，这个时候服务就ok了。

但这样处理只是暂时规避了，没从根本上解决问题，还需要提高后端处理逻辑，提高性能。