We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 7804
    • 80 Posts
    When we originally deployed our MODx site (around a year ago) we were seeing the "too many connections" error from MODx rather frequently. I changed some PHP code in our forum software that I thought was the issue, and the error did go away for a while.

    However, last night it reared its ugly head again. As a web-based business we simply cannot afford to allow our site to go down at random times without trying to do anything about it. For reference, we were seeing the same issue as discussed here several months ago:

    http://modxcms.com/forums/index.php?action=printpage;topic=27824.0

    We are running MODx on a dedicated load-balancing server along with some shopping cart software and phpBB. These are the only 3 things that ever make any connection with our database. We have our max connections limit set well above 1000; we do not use stats logging. We receive probably around or less than 10,000 visitors per day.

    I am not so much interested in whether or not MODx is causing this error as I am in eliminating all possible causes (there has already been a debate on these forums whether MODx can cause this, and that is not my intent). In researching this problem, I have seen that pconnect() may be a culprit. I searched the MODx directory for this function and found only 2 occurrences in the following places:

    manager\includes\extenders\dbapi.mysql.class.inc.php(87):
    if (!$this->conn = ($persist ? mysql_pconnect($host, $uid, $pwd) : mysql_connect($host, $uid, $pwd, true))) {


    \includes\db\mysql.php(48):
    $this->db_connect_id = ($this->persistency) ? @mysql_pconnect($this->server, $this->user, $sqlpassword, $new_link) : @mysql_connect($this->server, $this->user, $sqlpassword, $new_link);


    (It looks like to me that this code is checking for a ’persistency’ setting, I haven’t really looked into it so I’m not sure.) I am wanting to change these calls to from pconnect() to vanilla connect(). Can anyone foresee any issues if I do this? I can’t think of any but I wanted to be sure.
      • 26903
      • 1,336 Posts
      Looking at this code here ’manager\includes\extenders\dbapi.mysql.class.inc.php(87):’ the $persist variable should be 0 here so you will in fact call connect and not pconnect so your change here should cause no difference. Not sure where your second code line comes from but it should be OK to change here as well. Don’t know what platform your on but there are tools like ’mytop’ for instance that may help you see who is hogging these connections.
        Use MODx, or the cat gets it!
        • 7804
        • 80 Posts
        Thanks, and I really don’t think MODx of the cause of this. I think phpBB is at fault, and they have had a raging debate on their boards about this as well. I’ll look into the mytop tool... looks very promising. Thanks again.
          • 7804
          • 80 Posts
          Just an update to those of you who may be experiencing this error... This definitely is not a MODx error. In our case, the error was being caused by a gazillion open connections from phpBB.

          I found this:

          http://jayant7k.blogspot.com/2007/07/mysql-waittimeout.html

          ...and changed the MySQL wait_timeout variable from 28880 (8 hours!) to 200 (a little over 3 minutes) and it seems to be helping so far.
            • 7804
            • 80 Posts
            One final update for anyone who may have found this thread searching for a solution for this problem: this issue is definitely caused by phpBB3 and specifically, the fulltext-native search option (In fact I think one user was able to narrow this down to a spammer running an extraordinary amount of search queries on the forum). If you are running phpBB3, change your search type from fulltext to mysql and you shouldn’t see this problem anymore. If you’re not running phpBB3, well then... keep searching. smiley