In our PHP application, we use some Access databases for compatibility with our desktop application. We connect using odbc_connect and DRIVER=Microsoft Access Driver (*.mdb);DBQ=$filename;. This works as expected with most customers...
Some customers experience problems, apparently an error message about a connection limit of 25 connections is thrown and no more connection is possible until the Apache is restarted. Sadly, I have not yet gotten an exact error message, but maybe someone knows this problem already and can enlighten me.
In some cases, it obviously worked to run Apache in CGI mode as the connections get closed after the script finished. But some customers even experience problems in CGI mode.
Is there any way to increase the number of connections or to quickly close the connection? The wierd thing is that I tried to force the problem to appear on my PC, but even with hundreds of concurrent connections I did not have a single error, and the connections seem to close after the script finishes as the .ldb file disappears again.
Maximum connections is set on the webserver in the php.ini with the "MAX USER_CONNECTIONS". When running on localhost, this is rarely a problem. I hade this problem only a few days ago actually when using PDO and MySQL. It worked on localhost, but when I transfered it to a webhosting company it did not work. I solved it by setting persistance to TRUE in the database connection (Means that connections are kept in memory instead of making new connections at each call) If you want more info about this: http://www.php.net/manual/en/features.persistent-connections.php
I would therefore recommend trying ODBC pconnect: http://www.php.net/manual/en/function.odbc-pconnect.php
Related
Recently, from few weeks ago I got err_connection_timed_out just sometimes while working with my website.
and i am sure, my users get this error too.
When i see at error log, there are a few of message like below
PHP Warning:mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock
I changed 'localhost' to '127.0.0.1' for TCP connection instead of Unix socket, but no success.
My server host admin do not accept any problem at server side (like always!).
I asked them to restart Mysql, but they do not accept because it is a share server.
It is a Directadmin server and they recommend switch to Cpanel as the last chance.
Do you have any experience and solution for this problem?
EDIT: The main problem is err_connection_timed_out which i get in browser and i don't know if it relates to Mysql connection error in log file.
Switching might have positive effects because it's differently setup.
But if it happens sometimes it is probably the MYSQL server is burping.
Lately it's normal that the services has limit per user; so you can try to enable cache (of that is possible); to see whether it's less frequent (might be some queries that is running long).
do you have any cronjobs running or other processes around the time you receive those errors?
Normally this problem is caused due to MySQL server timing-out database connections is faster than the Stash connection pool can notice. This exhausts the Stash connection pool as it will keep its connections open while the MySQL side of the connections is already closed.
Easiest solution.
You can fix it by simply change this parameter (wait_timeout) at the Mysql config.
More difficult but better
Also you can close all connections in your code after you got the values. And finally you can change your connection to your database in order to reuse an existing connections.
And last but not least
Try a vps you got out there too many oferts, even for free. You wouldn't be able to change anything in a shared host sorry. :(
When connecting to the database with a persistent connection (to avoid the connection time overhead), PHP warns that the "server has gone away". This is the code I use:
$db = new mysqli("p:10.0.0.1", "user", "pass");
I looked at the following questions:
PDO: MySQL server has gone away
Solving "MySQL server has gone away" errors
PHP mysqli reconnect problem
What would cause PHP to ignore mysqli.reconnect setting?
Error on connecting to MySQL database using PHP scripts
mysqli::__construct(): MySQL server has gone away
PHP mySQLi:: MySQL server has gone away
PHP cant connect to MySql (MySqli)
other search results from https://stackoverflow.com/search?q=mysql+server+has+gone+away+php+connect+is%3Aq
And a bunch of others. None of them are exactly the same as my issue: they either have long-running scripts or queries, or they ask how to automatically reconnect upon this error. In my case, it's not a long running script (it's a connection pool), and it's not an error: the scripts seem to work fine, it just outputs this ugly warning. PHP's connection pool just contains connections that have since timed out.
On my previous server, I very rarely saw this warning. In fact, there was an issue with hanging pages (now resolved) which would often show this warning or error (I don't remember which) after a few minutes. I never figured out what the issue was, but it seems related.
I want to avoid having to change every script, as there are hundreds of small applications running on the server (each is standalone and has its own database credentials). Adding an # in front of each connection has the side effect that it suppresses all errors, not just this particular one, and feels like a workaround instead of solving the underlying issue.
Is this just a bug in PHP, or is there a configuration setting that resolves it? I saw someone recommending a longer timeout on MariaDB's side, but that just lessens the frequency with which we'll see the warnings instead of resolving the issue fundamentally. Can PHP check its pool from time to time, or just discard old connections from the pool?
I also checked the documentation pages (1, 2), but the docs nor the comments mention this issue.
I'm using mysqli connection over ssl,
so using in code following:
$mdbconnection = mysqli_init();
$mdbconnection->ssl_set('/ssl/xyz.pem', '/ssl/abc-cert.pem', NULL, NULL, 'AES256-SHA');
$mdbconnection->real_connect(SV_SERVER, SV_MYSQL_LOGIN, SV_MYSQL_PASSWORD, SV_MYSQL_DATABASE);
I noted down that I am not able to connect over mysql server all the time.
if trying 100 times failing 3 time.
and getting following error
echo($mdbconnection->connect_errno);
printing:
2003
and if I am trying second time after failing it{echo($mdbconnection->connect_errno);} will give always 1045.
I am trying to solve this bug.
Any ideas would be appreciated.
The 2003 error code means the connection couldn't be established:
https://dev.mysql.com/doc/refman/5.5/en/error-messages-client.html
Error code 1045 means the client connected but the server rejected the credentials (access denied):
https://dev.mysql.com/doc/refman/5.5/en/error-messages-server.html
I'd say that if you're getting the 2003 error code a few times out of every 100 tries, it sounds like some of the possibilities could be:
Some intermediate application or piece of hardware might be seeing your attempts as a possible flood attack (DDoS) and could be intercepting and blocking the connection (if you're connecting 100 times really quickly)
You might have some network stability issues on the client side. It might be worth the time to run Wireshark and reproduce the problem with it running in order to capture the problem and see if it shows anything significant (e.g. DNS failure).
The MySQL server might be crashing and then restarting. Check your server-side MySQL error log (https://dev.mysql.com/doc/refman/5.7/en/error-log.html). Actually, you should really do this as a first step any time you have bizarre behavior in MySQL.
If the MySQL server log doesn't show anything, check your system logs, especially if you're logging anything like blocked firewall (iptables or whatever f/w you're using) packets and search them for your client IP around the time of the problem.
Finally, if you can reproduce this easily/quickly (e.g. make 100 connections via a script and see it fail), try eliminating SSL out of the equation and connecting without SSL and see if it gives you the same problem. If it works flawlessly without SSL, perhaps there's a problem with the SSL library that was used during the compilation of your MySQL package.
You might also want to check to see if you have any load-balancing in place that might make your script connect to different instances of the MySQL server (this is less likely, but could explain the symptoms you're seeing if one server is down and the next doesn't have the credentials you're providing)
If MySQL is dropping connections in a PHP application, and MySQL connection limit is set above the number of concurrent users in the application, which other factors can contribute to this behavior? Also, analyzing moodle logs (the only app running at these servers), yesterday I had 4 times more activity and it didn't drop anything, but today there were times where it was frustrating the number of dropped connections.
My main question here is why the database is rejecting connections when it didn't before with 4 times more activity (and everything it's the same, I didn't change anything in between).
Some background: I've got 2 servers contracted at my hosting:
shared server running Debian Linux/PHP 5.3 (FastCGI)
VPS running Debian Linux/MySQL 5.1.39
On this environment I'm running only moodle 1.9.12 (for the database connection using adoDB and persistent connections), php part on the shared server, database on the VPS. I suspect that, by PHP running on a shared server, other hosting accounts are affecting me (the database rejecting connections I mean, I really don't care about RAM/CPU).
Reading about the issue I've seen in places that persistent connections don't work well with PHP as CGI/FastCGI and that if both servers are in the local lan it really doesn't matter using persistent or not persistent connections because of the connection is going to be quick anyway. So now I'm using not persistent connections. I guess that may be part of the problem, but I fail to understand why it worked with more load. Which PHP/Apache settings are involved here?
Since your database and web server are on two different machines, there are two other possible causes: the network in between, and the network layer of the operating system.
If you did not change anything in your configuration and it worked with higher loads before, it is more likely to be an issue with the network connectivity between the two machines. Since the database machine is a VPS you also don't know how much real network load it is handling. If your ISP has competent support personnel (which unfortunately isn't always the case) it can't hurt to ask them if they have an explanation.
The same goes for your "shared" web-server. While it is unlikely, it is not impossible that it is a an issue of too many connections on that machine.
It would also help to know how exactly you are measuring dropped connections. If you are looking at the aborted-connections counter of mySQL, it is not necessarily a measure of an actual problem: http://dev.mysql.com/doc/refman/5.1/en/communication-errors.html. A user aborting a page load already may increase this counter.
If PHP throws an error, because it could not connect to the server or lost connection to the server during a query, then it is an issue.
We've got an ongoing issue where php 5.2.6 will quit connecting to Oracle 10.2.0.4.0. We can go weeks without any issues and then (usually Saturday mornings) php will no longer be able to connect. The database is up and running and we can connect to it manually with varous DB tools but php won't ever connect again until we reboot the web server. The web server is running IIS 6.0.
We connect using $connection = oci_connect ($userID, $password, $TNS) where $TNS is the appropriare TNS in the local tnsnames.ora file. We go through a connection manager at our data center but I don't know the details on how that works.
One of the reasons this has been dogging us is that we're not really sure who is causing the problem and the various logs haven't shed any light on that. Is it a php issue as it would appear or is the DB itself for some reason rejecting the connections, or is it perhaps the connection manager? Some input in figuring that out would help a lot. Our load is lighter on weekends so that should be the issue. We haven't been able to find any outside processes that could be initiating the problem.
Not really a "root cause" solution, but if you're not using FastCGI, a switch to FastCGI might help with this issue. A PHP process in FastCGI does not live for "weeks". Since the oracle client is loaded dynamically into the PHP process, the automatic process restarts you get with FastCGI should be identical to a web server restart. You can always tweak the FastCGI settings to restart the process more or less often.
If you're using ISAPI, that probably is your root cause though. PHP and ISAPI are bad news when combined. Problems are almost inevitable.