By andrewtf on

We're getting constant errors on our Drupal site: either out-of-memory errors like this:

Fatal error: Out of memory (allocated 56623104) (tried to allocate 10279957 bytes) in C:\www\docs\includes\database.mysql.inc on line 301

or connection resets or occasionally even the dreaded "MySQL server has gone away".

Researching the issue here points to a resource or settings problem with the database server, but our server admins in the IT department have maxed out all the settings on the web and MySQL servers and that shouldn't be an issue.

Right now it seems that the site is trying to consume gigbytes worth of memory doing something—what I'm not sure. Any ideas?

⋅ Categories: Drupal 6.x

Comments

wjaspers’s picture

wjaspers commented

You probably have some custom code that is running recursively and never escapes.
This is very likely since you're hitting both MySQL errors and memory allocation problems.

andrewtf’s picture

andrewtf commented

I'll check out that avenue. Not sure what it would be, but then I'm at a loss everywhere else at this point so it's a place to start.

andrewtf’s picture

andrewtf commented

Removed the site's custom code and found it didn't make much of a difference. Tried tracking down anything that was causing PHP errors in the dblog, too. Any other ideas? I notice that we're usually OK adding content or editing it, but trying to change a site setting sends the server way out into error-land.

wjaspers’s picture

wjaspers commented

Other possible issues:

  • Are you using views?
    • Look for views that have extremely complex query construction. (You can find out by turning on the "Show query" option for the Views UI settings).
    • If you have a large dataset being retrieved, and your site is very busy:
      • You may want to turn on Views' caching mechanisms
      • You may want to install a 3rd party caching mechanism, like Varnish.
      • APC (alternative PHP cache) does a wonderful job of pooling your site's code, (and drastically speeds up Drupal).
  • Are you using memcached? If so, make sure your caches are cleared or expire in a reasonable amount of time. I've made the mistake before of not setting this, which can cause the cache pool to fill, and crash the server. Some don't use memcached at all anymore.
  • Are you using features?
    • If not, you can export things like Node types, Views, system settings, and more.
    • This will put field definitions and views configurations into code, making them run a little faster.
  • Are you using a shared hosting environment? This is a really common problem, especially if MySQL isn't running on the same server as the filesystem.
  • Maybe PHP or an extension for it is corrupted?
  • Are you using Apache or NGINX? Nginx is faster, but will take a little work to learn, as it doesn't use .htaccess files at all.
    • andrewtf’s picture

    andrewtf commented

    Thanks for the great suggestions!

    The site is definitely views-heavy, so I'll check out the queries and see what I come up with. AFAIK there's nothing too complex at work there, but you never know.

    I'll ask our server admins about a 3rd-party cache. It's something I've looked into already, and you're confirming it's a good idea.

    The site is on a dedicated Apache server that supposedly has tons of power and resources behind it, but MySQL is not (I'm pretty sure) running on the same server.

    One more thing to mention: We have a sandbox environment set up with the exact same site, and it runs flawlessly, so either the problems on the live site are because it's under a load (252 anonymous users as I write this) or because of the hosting environment.

    andrewtf’s picture

    andrewtf commented

    After a huge amount of troubleshooting and even some back-and-forth with a Drupal hosting consultant, I think our sysadmin finally managed to solve this problem by limiting the number of MySQL connections available to Drupal to 20. Not sure how he arrived at this idea, but as soon as he did it the site stabilized and all became right with the world, at least for the time being.