When i was checking for mysql load time on site. i got result showing connections as TIME_WAIT. Even though i close connection on every page. Sometimes the site doesnt load saying too many connections. What could be solution to this problem?
Thanks in Advance for any replies or suggestions
If a client connects to a MySQL-Server, it usually opens a local port, example:
localhost:12345 -> mysqlserver:3306
If the client closes the connection, the client gets a TIME_WAIT. Due to TCP routing, a packet might arrive late on the temporary port. A connection in TIME_WAIT just discards these packets. Without a TIME_WAIT, the local port might be reused for another connection and might receive packets from a former connection.
On an high frequent application on the web which opens a mysql-connection per request, a high amount of TIME_WAIT connections is expectable. There is nothing wrong with it.
Problems can occur, if your local port range is too low, so you cannot open outgoing connections any more. The usual timeout is set to 60 seconds. So a problem can already occur on more than 400 requests per second on low ranges.
Check:
To check the amount of TIME_WAIT, you can use the following command:
$ cat /proc/net/sockstat
sockets: used 341
TCP: inuse 12 orphan 0 tw 33365 alloc 23 mem 16
UDP: inuse 9 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
The value after "tw", in this case 33365, shows the amount of TIME_WAIT.
Solutions:
a. TIME_WAIT tuning (Linux based OS examples):
Reduce the timeout for TIME_WAIT:
# small values are ok, if your mysql server is in the same local network
echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout
Increase the port range for local ports:
# check, what you highest listening ports are, before setting this
echo 15000 65000 > /proc/sys/net/ipv4/ip_local_port_range
The settings /proc/sys/net/ipv4/tcp_tw_recycle and /proc/sys/net/ipv4/tcp_tw_reuse might be interesting, too. (But we experienced strange side effects with these settings, so better avoid them. More informations in this answer)
b. Persistent Connections
Some programming languages and libraries support persistent connections. Another solution might be using a locally installed proxy like "ProxySQL". This reduces the amount of new and closed connections.
If you are getting alot of TIME_WAIT connections on the Mysql Server then that means that Mysql server is closing the connection. The most likely case in this instance would be that a host or several hosts got on a block list. You can clear this by running
mysqladmin flush-hosts
to get a list of the number of connections you have per ip run,
netstat -nat | awk {'print $5'} | cut -d ":" -f1 | sort | uniq -c | sort -n
you can also confirm this is happening by going to one of your clients that is having trouble connecting and telnet to port 3306. It will thow a message with something like,
telnet mysqlserver 3306
Trying 192.168.1.102...
Connected to mysqlserver.
Escape character is '^]'.
sHost 'clienthost.local' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'Connection closed by foreign host.
As #Zimbabao suggested in the comment, debug your code for any potential errors that may halt the execution of closing the Mysql connection.
If nothing works, check your my.cnf for a system variable called wait_timeout. If its not present add it to the section [mysqld] and restart your Mysql server.
[mysqld]
wait_timeout = 3600
Its the number of seconds the server waits for activity on a noninteractive connection before closing it. Further information can be found http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_wait_timeout
Tune the figure 3600 (1 hour) to your requirements.
HTH
Related
What a strange problem!
I have the same applications running in different mysql(dev and test environment)
both 2 mysql are totally the same.
but today in dev environment, I came up with an error like this(which is never happened before):
Host 'Hostname' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts
I also find the solution to this problem, like below
here is the solution of same question but not solved
there are 24 connections in the connection pool of my applications, none of them will fail and there are also no failures at all.
Using show variables like "%max_connect%" I can see max_connect_errors are 100.
My application runs in the same ip as my navicat.
By show processlist I can see there are no other connections except navicat connection before application start. And then I tried to start my application, the problem occured and I cannot even start up my application!
after flush hosts, all the applications will be run in normal without any problem, but when I tried to restart them, the problem shows again.
I don't know what's going on!
I have 4 applications using DB, and the mysql configuration is showing below:
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://${my-config.mysql.host}:${my-config.mysql.port}/${my-config.mysql.db-name}?characterEncoding=utf-8&serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true&allowMultiQueries=true
username: ${my-config.mysql.username}
password: ${my-config.mysql.password}
validation-query: SELECT 1
test-on-borrow: true
test-while-idle: true
time-between-eviction-runs-millis: 10000
hikari:
minimum-idle: 1
maximum-pool-size: 10
you can see that: even all the applications use connections in the maximum pool size, ther should be only 40 connections, and also even all of them failed there are only 40 failures.
So far I have noticed that using show processinglist after flush hosts there are always 1 or 2 unauthorized connections like this:
maybe this is why my application will always down after restarting.
But I notice that that unauthorized connection is from my computer and I did not run any other applications...
Another problem is that, when the problem occurs, it shows
Host '192.168.18.19' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'"
but all the other existing connections using the same IP will not receive such report, they works well and can reach to mysql!
you can see that my gateway application was toasted because of the problem.
but my message center application using the same IP can get infomation from mysql(only if it can get rows from mysql, it print those words like 配置已更新).
If mysql blocked my IP, why other applications using the same IP will not be blocked?
Am I hacked?
I'm trying to scan list of IP addresses using below command
nmap -v -n -sP -iL <IP-list-file.txt>
here I'm looking retry option with nmap command for the failed probe retransmission. Above command will do a single ICMP probe for each IP/hosts. Even I tried with --max-retries no result. So I'm looking a similiar option like { ping -c<2> IP > along with this nmap.
Even tried "-A -T5" no result
Note:- My purpose is to check only whether the host/IP is alive or dead that's it. Preferably nmap utility.
Nmap uses a lot of different methods for host discovery. The options that you used will do one of two things depending on whether you have root privileges:
If you do run Nmap as root, it will send four probes: ICMP Echo Request, TCP SYN to port 443, TCP ACK to port 80, and ICMP Timestamp Request. Only if all four fail to get a response will it mark the target as down.
If you do not run Nmap as root, it will attempt to make a TCP connection to port 80 and port 443. If both of these time out, it will mark the target as down.
So this method is already more robust than simply using /bin/ping. Nmap also retries probes a certain number of times depending on how reliable the network seems. For host discovery, this starts out at 2 retransmits per probe. There doesn't really seem to be a way to increase this without Nmap detecting network problems, so the best way to increase confidence in a "down" determination is to add more host discovery probes using the various -P* options.
The -A and -T5 options will not help at all. -A turns on extra features, none of which will run if the target is considered down, and -T5 simply tells Nmap to assume a very fast and reliable network. It will never retransmit more than 2 times, and will time out probes very quickly. This is almost certainly the opposite of what you want.
I'm running MariaDB v10.0.14 on a Windows 2012R2 Server, and I work locally from a Win7 machine. I'm limiting this problem to using the command line client tool. I am encrypting the connection to the server DB with SSL. I can connect and issue commands, however after being idle for 60s I get:
ERROR 2013 (HY000): Lost connection to MySQL server during query
When I re-issue the command I get:
ERROR 2006 (HY000): MySQL server has gone away.
No Connection. Trying to reconnect...
Then the client reconnects and runs the command. I don't know why this is occurring and am worried it may affect DB users' connections. Some troubleshooting:
When I connect without SSL this does not occur
I have been ignoring this issue for a while so can not say what change may have led to this. I certainly remember connecting with SSL in the past and not having these timeouts.
I can RDP to the server, connect to DB with command line tool and SHOW FULL PROCESSLIST. I can see the localhost connection plus the remote client connection. When the client has just been started I see Command as 'Sleep' and State as 'cleaning up'. I can issue commands from the client. When Time > 60 State changes to Null and the client shows the above symptoms.
I've read through this, tried all standard suggestions but can't even seem to find any mention of this behaviour. Is it normal?
Wait_timeout and interactive_timeout are set at 28800 so I don't think this is the problem.
net_read_timeout=30 and net_write_timeout=60 but these are tiny commands
connect_timeout=10 but connection is not the issue.
Credentials and permissions are fine as I can connect originally.
Error log has entries corresponding to this event as:
Aborted connection xxx to db: <dbname> user: '<user>' host: '<host>' (Unknown Error)
Firewall logs show that traffic seems to be flowing just fine.
I took a capture of network traffic on the server and saw the below. The blue is the original connection. In orange you can see that at 73s I issue a new command which is met in red with [FIN, ACK] then [RST, ACK] from the server. The green afterward is when the command is reissued and the reconnection occurs. Note the change in client port. Handshakes seem to be fine. Beyond that I'm lost. I'm a data guy, not a network guy.
Anyone have any insights or ideas? Thanks.
Output for
show variables like '%timeout%';
(can't post more than 2 links. I should answer some questions)
connect_timeout=10
deadlock_timeout_long=500000000
deadlock_timeout_short=10000
delayed_insert_timeout=300
innodb_flush_log_at_timeout=1
innodb_rollback_on_timeout=OFF
interactive_timeout=28800
lock_wait_timeout=31536000
net_read_timeout=30
net_write_timeout=60
slave_net_timeout=3600
wait_timeout=28800
Sorry if it comes a bit late, but the reason is this bug https://jira.mariadb.org/browse/MDEV-9836 . SSL connection were aborted after net_read_timeout (which is quite short) not after net_wait_timeout.
I'm setting up a PrestaShop installation on a development server which is a GCE instance and using Cloud SQL as a database server. Everything works just fine except one thing: whenever there is a long period of inactivity on the site, the first page load after that always gives me this error:
Link to database cannot be established: SQLSTATE[HY000] [2003]
If I refresh the page the error is gone and never appears again until I stop using the site for an hour or so. It almost looks like database instance is going into sleep mode or something like that.
The reason I mentioned Prestashop is the fact that I never get this error when using Adminer or connecting to the database from mysql console client.
With the per use billing model, instances are spun down after a 15 minute timeout to save you money. They then take a few seconds to be spun up when next accessed. It may be the Prestashop is timing out on these first requests (though I have no experience with that application).
Try changing your instance to a package billing, which has a 12 hour timeout, to see if this helps
https://developers.google.com/cloud-sql/faq#how_usage_calculated
According to GCE documentation,
Once a connection has been established with an instance, traffic is permitted in both directions over that connection, until the connection times out after 10 minutes of inactivity
I suspect that might be the cause. To get around it, you can try to lower the tcp keepalive time.
Refer here: https://cloud.google.com/sql/docs/compute-engine-access
To keep long-lived unused connections alive, you can set the TCP keepalive. The following commands set the TCP keepalive value to one minute and make the configuration permanent across instance reboots.
# Display the current tcp_keepalive_time value.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
$ echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf
# Apply the change.
$ sudo /sbin/sysctl --load=/etc/sysctl.conf
# Display the tcp_keepalive_time value to verify the change was applied.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
I am using 3 servers and one database server. I use private ip to connect to mysql server. But i get this kind of error many time.
I tried to turn off mysql.allow_persistent in php and raise max connections and connection error in mysql server but no effort.
Please help me to fix this issue.
Link-ID == false, connect failed
mysql error: Too many connections
I also saw a lot of TIME_WAIT connected over port 3306. How can i tune MySQL server properly.
Thanks
I believe that the max_connections setting is not a limit for the total number of connections, but rather the number of connections that a single user can open.
To help fix this, be sure that:
You're closing connections when finished, using mysql_close()
You're not using persistent connections - bad idea!
Try running SET GLOBAL max_connections = ### in SQL, replacing the #s with a desired amount.
Look in and modify your my.cnf file to change the max # of connections - watch out for memory/load issues.