Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2815389
  • 博文数量: 587
  • 博客积分: 6356
  • 博客等级: 准将
  • 技术积分: 6410
  • 用 户 组: 普通用户
  • 注册时间: 2008-10-23 10:54
个人简介

器量大者,福泽必厚

文章分类

全部博文(587)

文章存档

2019年(3)

2018年(1)

2017年(29)

2016年(39)

2015年(66)

2014年(117)

2013年(136)

2012年(58)

2011年(34)

2010年(50)

2009年(38)

2008年(16)

分类: LINUX

2014-09-10 15:35:42

How to track down the source of Aborted_connects
August 23, 2008 by Baron Schwartz 20 Comments
 ##转之percona performance blog
Yesterday I helped someone who was seeing a lot of “server has gone away”  error messages on his website. While investigating this problem, I noticed  several things amiss, which appeared to be related but really weren’t. The biggest measurable sign was  


 
[percona@server ~]$ mysqladmin ext | grep Abort
| Aborted_clients                | 14835        |
| Aborted_connects               | 15598        |
These two status variables are actually unrelated (see the manual page that  explains them). The first was related to the errors the client was seeing: the server was closing inactive connections after a while, and I fixed it by increasing the wait_timeout configuration variable.
The second error does not indicate that an active connection is closed at all. Rather, it shows that a connection cannot be made for some reason. Perhaps it ’s networking, or perhaps there’s an issue with permissions or something  else. The first thing I did was look for packet loss between the database server and the web server; the network appeared to be working fine.
With that ruled out (at least, to my satisfaction) I turned to tcpdump to see what was happening with these connections. I ran the following command in one window of my screen session, so I could see when a connection was aborted:
  
[percona@server ~]$ mysqladmin ext | grep Abort | grep -v 0
And then I started tcpdump in another window:
  
[percona@server ~]$ tcpdump -s 1500 -w tcp.out port 3306
After I saw an aborted connection, I cancelled tcpdump and looked at the  resulting file. Inspecting the session with tcpdump -r showed that there was a complete TCP session; nothing bad was happening at that layer. So I used the strings utility to look at the text sent in the packets:
 
[percona@server ~]$ strings tcpdump.out  ###个人体会,如果该文件内容太多的话,一屏显示不了,可以将结果写入到一个文件里面,然后通过cat或vi等来查看文件的内容
Host 'XXX.XX.XX.XXX' is not allowed to connect to this MySQL server
I’ve anonymized the offending IP address. However, I checked the server’s grant tables and indeed. that IP address (which is a machine in the local network) is not allowed to connect. I don’t actually use tcpdump much, but this was a fun little exercise that I thought I’d share with you.

阅读(2693) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~