While many possible errors can be covered by the title of this thread (General Error SQL ERROR [ mysql4 ]), most posts seem to be concerned with two kinds of MySQL errors:
Error #1040 ('max_connections' exceeded)
Error #1203 ('max_user_connections' exceeded)
although posters haven't always said explicitly which error they experienced. (I was guilty of this myself in my previous post at
http://www.phpbb.com/community/viewtopi ... 5#p4876775 but I'll note that mine was the #1203 error.)
One thing I'm curious about: Can anyone explain the exact difference between the 'max_connections' and 'max_user_connections' variables? Both involve simultaneous connections. Do they play essentially the same role? What values do hosts typically set for these parameters?
What can be causing all these errors? Marshalrusty pointed out in post
http://www.phpbb.com/community/viewtopi ... 5#p4177865 that every process in phpBB3 closes its DB connections when it finishes. This leaves the question: What if a process fails to finish normally but dies with, say, an "Internal Server Error." Wouldn't that leave an open DB connection?
It's possible that phpBB3 is more prone to Internal Server Errors than phpBB2. For one thing, they can occur when running the phpBB2 to 3 converter. As I explained in another thread in post
http://www.phpbb.com/community/viewtopi ... 5#p4864675 - when I ran the converter, I restarted it repeatedly after it died with Internal Server Errors. (I was aware that the conversion can be done offline as described at
http://www.phpbb.com/kb/article/offline-conversions/ - but the brute force method of restarting repeatedly after errors just seemed so much easier. And I'm sure a lot of other people have done it the way I did.)
By checking our server logs, I've determined that when I ran the converter (a week ago from today), I restarted 43 times after errors. Then, when I rebuilt the Search index following conversion, I restarted another 18 times after errors. Those errors during the conversion and search index rebuilding may have already left a bunch of open DB connections, increasing the likelihood of hitting my host's limit after we went live with phpBB3.
A scan of our server logs shows that some Internal Server Errors ("500" status codes) continued to happen during normal operation of our phpBB3 board. They've happened during various operations such as searching, posting, viewing topics, UCP and ACP. But the greatest number of these "500" errors, by far, appear to be connected with the
cron.php script. This suggests the possibility that cron.php may be buggy, so the developers ought to examine it very carefully.
Meanwhile, in an effort to limit the problem, I'm experimenting to see if bumping up PHP's memory limit would help. Depending on your host, you may or may not have any ability to do this. In my case, although I'm on a shared host, they do allow each account its own php.ini file. The default memory_limit in these files is provided as 32M, but I've tried increasing it to 60M which is, I believe, the maximum that the host's shared servers will allow. It's unclear whether this will reduce the number of "500" errors, although the board does seem somewhat "zippier" since I did it about 9.5 hours ago. During this period, the server log shows just one "500" error - and it happened in a "cron.php" process.