I keep getting "Lost connection to MySQL server at 'reading initial communication packet'" on my gear which happens every 2 to 3 hours. My gear is a scaled instance with php and mysql
First I would check to make sure you're not hitting any memory limitations on your app. Check out this FAQ to find out how to check https://www.openshift.com/kb/kb-e1082-how-to-check-for-memory-limit-violations.
If you are hitting memory limit's then I would suggest creating a scalable app which will put your app and database on separate gears.
Related
I am using Springboot for Server side development and mysql workbench is showing more than 800 connection in development server when no user is connected or online. Here is the screenshot of mysql workbench server status.
Please help how am i getting these number of connection and how can I rectify this error.
When you deploy a spring-boot application it creates a connection pool which sits idle if there is not load on the server (meaning in your terms that no user is online) these connections are still maintained. Hence, when you check the number of DB connections from WorkBench, it'll show you that many number of connections used by server.
I have aplications that connect to a remote server (MySQL 5.5 on Windows Server 2012), at first I started receiving "too many connections" message which I solved by increasing MAX_CONNECTION value in my.inf to 500, then I start getting "can't create new thread" message so I decrease decrease timeouts to avoid idle connections using a socket, which didn't completely work. Now I get odd messages like 'file not found', as soon as I restart the service I stop getting the messages and everything works correctly.
The problem occurs when the server reaches around 170 connections at the same time.
Is there some configuration I'm missing?, I really don't know what info you need to give me a hint to fix this. I mean, there are servers that accept a lot morw of connections at the same time, right? waht I'm missing.
RAM and CPU of the system dosen't reach 35-40% at max connections (170).
Edit: Error occur at 2 'places', when running a query or at the attempt of conennection, it's like the MySQL service rejects the attempt. VB6 is the language used in the client app (ODBC connector). The app opens, executes and closes the connection.
Note: I have full control over client app and server config.
I am running Ghost as a web service on Microsoft azure. I am using MySql Database for storage instead of the default Sqlite. Every time i open the blog i get a Econnreset error with status as 500, and Sql query is being shown.
I have MySql Running in a virtual machine. But everything works out fine on refresh. I am also using connection pooling.
How to rectify this, or what can be the probable reason for Ghost to drop connection with database.
Solved the problem. Issue is with the underlying Knex MySql Driver. When the connection remains Idle Azure closes the connection, when the request is made again knex does not check if the connection is still there or not leading to Econnreset Error.
You can fix this by setting min number of connections to be zero in knex.
For more details follow this issue:
https://github.com/tgriesser/knex/issues/975
Is the mysql database hosted on another azure instance ?
If so you will need to make it available to the outside (Open the required ports).
I setup an old Django app on a new GCE instance on Sunday and pointed it to a new CloudSQL instance with imported data there. This code and data has successfully run over the past few years on a variety of dedicated hosting setups, on EC2 and on EC2+RDS.
Since Sunday I have had intermittent reports of 2013, "Lost connection to MySQL server at 'reading initial communication packet', system error: 0" from the App. In particular today it happened in two bursts of 3 separated by about 7 hours.
I panicked in the earlier outages and restarted both the app and the CloudSQL instance which did the trick. However the latter ones today righted themselves after a few minutes.
I've never encountered this error before working with MySQL and any searching on the error gives results related to people who have general access problems to the DB.
On the GCE side the only difference I can think of from previous setups is that it is using Google's out-of-the-box Debian image instead of Ubuntu 12.04. On the MySQL side I have no idea as I've successfully run this on both MySQL 5.x and MariaDB.
Is there any way of figuring out why this is happening and fixing it?
Thanks.
Have you tried changing keep alive settings for TCP connections? GCE has a firewall rules that drops idle TCP connections after 10 mins:
https://cloud.google.com/compute/docs/troubleshooting#communicatewithinternet
You can check current value of 'tcp_keepalive_time':
cat /proc/sys/net/ipv4/tcp_keepalive_time
And change it to 60 seconds:
vi /etc/sysctl.conf
# Add this line
net.ipv4.tcp_keepalive_time = 60
# Reload Sysctl interface
sudo /sbin/sysctl --load=/etc/sysctl.conf
You might need to restart Django server to pick new keep alive settings.
Note: If this problem was limited to yesterday (18/11/2014) and your Cloud SQL instances are located in EU, you might have been affected by this:
https://groups.google.com/forum/#!topic/google-cloud-sql-announce/k5raPT48hc0
It seems there is an issue with the firewall, preventing incoming connections, just change the location from the server to another mirror things suppose to go fine. It worked for me
I have a web application which is currently running on Windows XP operating system with SQL Server 2005 database and IIS 6.0.
Now, we are trying to upgrade it to IIS 7.0 on Windows Server 2008 and SQL server 2008 database.
When I run the application then it is throwing "A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)" randomly at different database calls.
I have verified using "sp_who" that only one connection which I am using is opened.
Can anyone tell me, what could be the cause of this issue?
This blog post by Michael Aspengren explains the error message "A transport-level error has occurred when sending the request to the server."
Maybe the database is set to auto-close? This used to be the default for databases created on the older MSDE/Express edition.
ALTER DATABASE YourDatabaseName SET AUTO_CLOSE OFF;
More:
The SQL Server 2005 Express Edition Overview states:
Features like Auto-Close and the ability to copy databases as files are enabled by default in SQL Server Express ...
I can't remember which service pack changed the default, but the New Database UI in the SP3 version of Management Studio Express defaults the Auto Close setting to false.
This is an error that occurrs when connecting to database due to a lower layer network-related error that you cannot handle from Sql Server.
It would be great that the API used to conenct handled this error but AFAIK it is not. The only way to solve this is to retry connecting to the database when this error occurrs.
You should try to reconnect at least a couple of times more to get sure that the error is not persistent and if it is the case then throw the exception. My experience tells me that trying to reconnect, the 99.9% of times you will succed.
Often, it's the database being offline/closed or the SQL Instance being restarted/offline
In my case. We have DELL R720, NICs are on board and PCI Broadcom NetXtreme Gigabit Ethernet cards. We run into two issues.
Network speed is very slow for HyperV VMs. The solution is to disable the "Virtual Machine queues" of the HyperV host Broadcom nic property windows. It is in the Advanced tab.
SQL client having this transport level issue. It only happened once in every 10-15 min. At the same time the RDP service kick out client from time to time also. The solution is to disable the "Large Send Offload V2" of the HyperV host Broadcom nic property windows. It is in the Advanced tab.
Check if you have MultipleActiveResultSets=true; set in your connection string.
Transport level errors are often linked to the connection to sql server being broken ... usually network.
Timeout Expired is usually thrown when a sql query takes too long to run. Is this the scenario in your case? Like stored proc taking too much time to execute or are there are batch jobs that are executed?
Use clearpool(urSQLconnection), along with dispose. This will clear the dirty connection. and you can open new connection.
Got this trying to execute commands from multiple threads on one connection object in .net, that was a stupid mistake. Locking it or using a separate connection per thread fixes that.
In my case it was McAffee that was pre-installed. Can tell if it was conflict with other solutions or not. The connection was on VPN, on WiFI. Maybe this will help someone in future.