MySQL之aborted connections和aborted clients

最近线上遇到一个问题,接口日志发现有很多超时报错,根据日志定位到数据库实例之后发现一切正常,一般来说接口出现超时排查顺序如下:

  慢查询 -》连接数 -》 服务器负载 -》网卡流量,但是这次从QPS、连接数、服务器负载、IO消耗、响应时间及慢查询上都非常正常并没有什么异常发生,只有如下这个图有变化。

  在排除了前端服务器没有出现异常后,看来问题就出现在这个链接数变化上面了。为了看懂上面的图我们先说一下状态值的含义。

1、Max Connections和Max Used Connection

这两个就不细说了,分别是最大链接数限制和每个用户最大链接数限制。

2、Aborted Clients:

The number of connections that were aborted because the client died without closing the connection properly.

当ablort clients增大的时候意味着有客户端成功建立连接,但是很快就断开连接或者被终止了,这种情况一般发生在网络不稳定的环境中。主要的可能性有

  a)客户端没有主动关闭mysql连接mysql_close()。

  b)wait_timeout设置很短被mysql干掉了。

  c)客户端由于某些原因被干掉了。

3、Aborted Connection:

The number of failed attempts to connect to the MySQL server.

当有大量的链接连接不上mysql的时候,这个数值就会激增。主要的可能有:

  a)没有授权或者密码不对。一般错误日志中会有如下报错(Access denied for ‘user’@‘host’)

  b)连接数满了。一般报错包含(too many connections)

  c)超过链接时间限制,主要有这个参数控制connect_timeout(mysql默认是10s,基本除非网络环境极端不好,一般不会超时。)

4、Threads Connected:

The number of currently open connections.

也就是我们经常使用show processlist看见那个数值。

5、Connections

The number of connection attempts (successful or not) to the MySQL server.

所有尝试连接到mysql server的连接数,关键时不管成功还是失败。所以这个数值的增量并不等于show processlist的数值,这点需要注意。


 

了解以上参数之后,就可以分析这个图了,首先第一反应时连接数有增加,我们可以看到connections和thread connected都增加了,但是没有达到max connections的限制。

在仔细看图下的数据,我们发现abort connection和connections的max值和avg值基本一样,在仔细看图,可以发现蓝线和绿线基本重合了。

从上述参数含义看,在问题时间段所有尝试建立的链接都失败了,导致connections和abort connection同步增加完全重叠。

但是究竟是什么导致链接数上升,前端开始重建链接,由于当时的前端日志没有及时分析出来,故我们就不得而知了。但是有3个怀疑点:

1、由于mysql版本是5.5.12,所以可能遇到了max_connections的bug,可以见这个blog(http://www.cnblogs.com/billyxp/p/3408335.html),这种情况下,前端日志应该有非常多的too many connection是的报错。

2、短时间内有大量的大包传输,导致超过max_allow_packet的限制,导致断开连接。这个设置在server和client上都有,需要同步配置。同时前端应该报Got a packet bigger than ‘max_allowed__packet’ bytes这个报错。

3、超过max_connect_error的限制,导致某一个ip出现问题,不停的重试。(这个可能是最不可能,首先默认数值非常大,其次单个ip不应该出现这么大的影响。max_connect_error代表某一个ip连续失败超过n之后,server会拒绝这个ip的请求,只有flush host cache才可以解封。)

 

Top