Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a MediaWiki wiki on a MySQL database. However, other applications are also accessing MySQL. Currently we have a maximum of 100 maximum connections to the database, of which MediaWiki is allowed 10.

However, at peak times more than 10 users attempt to access the wiki simultaneously which means they can get a MySQL connection error.

Specifically, the message says:

"database name" has a problem

Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Can't contact the database server: Unknown error ("mysql database name"))

My thought is to limit within MediaWiki (e.g. in LocalSettings.php) the number of connections attempting to access the database. Then people won't get an error message - they will just have to wait longer.

Is there a way to do that? Or is there a better solution?

share|improve this question
up vote 2 down vote accepted

Within the application is where you would need to do precisely what you are wanting, yes.

I'll take a moment to recommend against that, first: It appears that the site is getting enough use that it needs more database connections, and this type of thing may not really be able to be helped overall. (I can only assume, for example, that MediaWiki is not written such that it is needlessly using extra connections than it needs to)

My basic thought here is, if at all possible, try to give the site what it needs to operate. If that would cause trouble with the shared MySQL server, perhaps that bottleneck needs to be addressed. Whether it's a wait or an error, failure to connect to the database will drive a certain number of users from the site, and is just generally creating a negative experience for them.

The 'easy' solution would be to change the error message to be a more friendly one, but that may not address the problems.

Assuming you can not raise the 10-connection limit, the application may need to be altered (and perhaps quite extensively) such that every database connection attempt is wrapped in code which catches failures to connect, waits a pre-determined time, and tries again a certain number of times.

You may be lucky, and MediaWiki may have such functionality in it which can be configured in. Someone more familiar could help with that, if so. Another (more likely) point of lucky-ness would be if the DB access code is very tightly contained, and so this solution would not be a matter of changing 300+ places in the code to do this (a time-consuming and aggravating prospect, to say the least).

I would only recommend such a solution if it is very infrequent that these errors happen. If it's a regular occurrence, it could just end up bringing the site to a crawl, where it's waiting/retrying DB connections constantly... and still ending up returning an error eventually, anyway.

share|improve this answer
And incidentally, you do not want to try to implement the above without a cap on the number of retries, or with a very high cap. If it's failing after trying more than so many times (in other words, if the server is not returning data to the web browser after so much time), continuing to wait will only compound the issue, and the user is likely to think the server has "hung up" anyway, and retry or do something else. After a certain amount of time, an error message is truly better than making them continue to wait. – Andrew Barber Nov 19 '10 at 11:03
thanks for both replies. So it seems like the best way to go is simply to up the number of connections. – Wikis Nov 19 '10 at 11:04
Yup, definitely. Well, there's no doubt at all that's the best solution as far as this one application is concerned. Just be sure it's not affecting other apps negatively, of course. – Andrew Barber Nov 19 '10 at 11:09
quite right! – Wikis Nov 19 '10 at 11:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.