forums › forums › Monyog › Using Monyog › Aborted_Connects Increasing – Causing High Percentage Of Refused Conne
Tagged: aborted refused connections
- This topic is empty.
-
AuthorPosts
-
-
February 8, 2013 at 3:31 pm #12922paulohm1Member
We have a php/mysql web application and we use monyog to monitor the mysql portion of it. We have multiple server environments, some of which use Debian + Mysql, some use Windows + Mysql.
I have noticed, once I add one of our servers in Monyog, the number of aborted_connects steadily increases over time on that server. I have monitored aborted_connects on servers that are not monitored by monyog, and these servers have aborted_connects = 0. Once I add that server to monyog, aborted_connects starts to increase.
I understand that the “Percentage of refused connections” counter in monyog is calculated by aborted_connects divided by connections. As such, the “percentage of refused connections” steadily climbs to high percentages in off-hours when the application is lightly used, because the number of connections decreases, while the aborted_connects stays the same, therefore increasing the percentage.
I am trying to find out why monyog is causing aborted_connects. I have enabled log_warnings=2 on all of my monitored servers. On my Windows + Mysql server, I do not notice any warnings of note. However, on my debian + mysql servers, I have many entries of the following errors:
[Warning] Aborted connection 154246 to db: 'unconnected' user: 'monyog' host: 'xx.xx.xx.xx' (Got timeout reading communication packets)
[Warning] Aborted connection 154228 to db: 'unconnected' user: 'monyog' host: 'xx.xx.xx.xx' (Got an error reading communication packets)
Obviously, when I disable the monitoring of the debian servers, these errors disappear. Please help me find the cause of all of the aborted_connects by monyog, which are causing false numbers for percentage of refused connections.
-
February 11, 2013 at 6:57 am #34162peterlaursenParticipant
Please tell: what is the 'wait_timeout' setting on this server (execute “SHOW GLOBAL VARIABLES LIKE 'wait_timeout';”), and what is the sample interval setting in MONyog.
MONyog uses persistent connection to MySQL but If sample interval is larger than 'wait_timeout' the server will disconnect MONyog after 'wait_timeout' idle seconds. MONyog will then reconnect automatically next time it queries the server.
'wait_timeout' has a default setting of 28800 (seconds = 8 hours) in MySQL, but this server may have set a lower value. Now say it is set to “120” (= 2 minutes) and sample interval in MONyog is 5 minutes, MONyog will be disconnected 2 minutes after it has retrieved data from the server last time. And each time the server increments aborted_connects.
-
February 11, 2013 at 4:00 pm #34163paulohm1Member
Thank you for the response. However, my wait_timeout is set to the default of 28800 seconds.
The only other timeouts I have explicitly set in my.cnf are:
slave_net_timeout=60 and innodb_lock_wait_timeout=50
Could either of these cause the same issue?
-
February 11, 2013 at 4:04 pm #34164paulohm1Member
Also, my collection interval in MONYog is 2 minutes.
I also have sniffing enabled which “sniffs” every 2 seconds.
-
February 11, 2013 at 5:50 pm #34165paulohm1Member
I always see connections from monyog in the “processlist” page that have a “command” of “sleep” and a “DB” of “NULL”.
If monyog is using persistent connections and correctly closing those connections, why are some of these connections left open in the “sleep” state?
I have attached an image of one such entry in the processlist page of monyog.
-
February 11, 2013 at 9:39 pm #34166paulohm1Member
I believe we have found that the cause of these aborted_connects is a load balancer in our environment which does a check of the tcp port (3306) on a regular basis. I will post back if I find otherwise.
-
February 22, 2013 at 10:52 pm #34167mattjulichMember
Hi Paul,
I'm running into a similar issue, numerous aborted connections behind an F5 load balancer. Mine seem to actually make connections to the db, then are aborted, then remade, than aborted, then remade, all without interaction from a user. Was there any specific setting you've found on your load balancer to tweak to halt that behavior, tweaks to the tcp port healthcheck?
Thanks
-
March 18, 2013 at 7:57 am #34168jjekabsonsMember
Hi all,
we have the same problem here.
Every time we use the process list we got every second a new entry in error-log:
[Warning] Aborted connection XXXX to db: 'unconnected' user: 'root' host: 'XXX.XXX.XXX.XXX' (Got an error reading communication packets)
– All timeouts are long enough.
– There are no load balancers or something else who can cause this issue.
Can someone help please.
Thanks
-
March 21, 2013 at 11:31 am #34169MaheshMember
Make sure that MySQL server detail entered is correct, also are you getting this error only on PROCESSLIST page?
You can go through this link wherein causes of communication errors has been mentioned http://dev.mysql.com/doc/refman/5.0/en/communication-errors.html
-
March 21, 2013 at 12:02 pm #34170jjekabsonsMember
The abort warning is only when I open the Processlist in MONyog, then every second I get a new warning.
And its only from MONyog, no other program or user works on that server.
I have checked all from your posted link and everything looks good.
Also the configuration for that server in MONyog is ok.
-
August 9, 2013 at 8:54 am #34171Mike CoultenMember
Hi, I am debugging similar errors on my mySQL 5.5 on RedHat linux servers
130807 22:44:32 [Warning] Aborted connection 8026 to db: 'ENERGYALERT' user: 'FLCF' host: '192.168.100.12' (Got an error reading communication packets)
We get these errors intermittently and often we get a group of connections all aborting i.e. all of our Matlab (JDBC) connections but all other connections are unaffected. We can simulate these disconnects by rebooting the server the client is on but logs show no reboots or users online at the time of the disconnects being investigated.
I dont think its MoNyog related but reading this ticket we will be turning off MoNyog monitoring on one db to test if it is
-
-
AuthorPosts
- You must be logged in to reply to this topic.