"out of memory" errors every day

Posted by webcomm on October 8, 2008 at 7:59pm

Hi,

I'm getting "out of memory" errors on my site almost every day. I've tried optimizing the cache tables, clearing the cache and even disabling the cache. The errors keep coming. Currently the error message is...

user warning: Out of memory (Needed 2092896 bytes) query: SELECT * FROM files f INNER JOIN upload r ON f.fid = r.fid WHERE r.vid = 9 ORDER BY r.weight, f.fid in /nfs/c03/h01/mnt/47382/domains/powervote.org/html/modules/upload/upload.module on line 566.

The PHP memory limit for this site is 99M.

There is a custom module on the site that was written by my predecessor. I don't know if it is the culprit. I'm not even sure why it was written in the first place, but I can't disable it because it seems to have a role in providing the output for all the content types as well as handling of various forms.

The web host says they can find no problem on their end.

-Ryan

Comments

mine just started today as

Posted by llizards on October 8, 2008 at 8:09pm

mine just started today as well... not sure whats going on...

Out of memory errors

Posted by michaelaj on October 9, 2008 at 3:48am

I too just started getting similar errors today. I have a 5.10 install with Ubercart, and started by receiving the following error:

Out of memory (Needed 2091016 bytes) query: SELECT DISTINCT nid FROM node WHERE type = 'donation' in /nfs/c03/h01/mnt/49585/domains/omahavna.com/html/includes/database.mysql.inc on line 172.

I thought the culprit might be the Ubercart Donation Products module, so I disabled it. I then started getting the following error upon every cron run:

Out of memory (Needed 2091024 bytes) query: SELECT GREATEST(COALESCE(c.last_comment_timestamp, 0), n.changed) as last_change, n.nid FROM node n LEFT JOIN node_comment_statistics c ON n.nid = c.nid WHERE n.status = 1 AND ((GREATEST(n.changed, COALESCE(c.last_comment_timestamp, 0)) = 0 AND n.nid > 0) OR (n.changed > 0 OR c.last_comment_timestamp > 0)) ORDER BY GREATEST(n.changed, c.last_comment_timestamp) ASC, n.nid ASC LIMIT 0, 100 in /nfs/c03/h01/mnt/49585/domains/omahavna.com/html/includes/database.mysql.inc on line 172.

This has killed the site's search functionality, as it can't index the content, and my user accounts have vanished from the "List users" screen.

I can't figure out the problem. I have a 99M memory limit with my host (Media Temple Grid Service), and have tried upping the memory limit to 256M...which doesn't help.

I'm stumped.

**Follow Up** I just upgraded to Drupal 5.11, but it did help fix the issues.

also on MT - but not seeing this with d6.4

Posted by zilla on October 9, 2008 at 3:57am

haven't done the 6.5 release that came out today, but i was getting some errors earlier this week - actually getting white screens when doing admin tasks - called MT and they advised me to reset the php.ini back to 99M (had it at 128) - but i'm not sure that's the problem...sounds similar, somehow related...

so at any rate, i used their nifty sql tools, ran the slow queries log, repaired the tables and all of that - but there really were no screwy long queries and nothing else seemed unusual, and i'm not using ubercart, just stuff like views, cck, og and so on...

i have read some stuff about modules not using inner join and in turn burdening the servers and tables on lookups...but i'm not a programmer and have no idea how to dig into modules to see what might be a culprit, and not so sure that it's even a module!

........................................................................
i love to waste time: http://twitter.com/passingnotes

Funny, I'm running into

Posted by webcomm on October 9, 2008 at 8:34pm

Funny, I'm running into these problems on Media Temple too. They insist it's not on their end.

ahhh, three of us! now we can point them to a thread!

Posted by zilla on October 10, 2008 at 3:34pm

i think we should all log in over the next couple of days and submit the same issue AND all point to this specific thread!!!

title: drupal memory issues
summary
link to this thread:

........................................................................
i love to waste time: http://twitter.com/passingnotes

I'm having this problem too...

Posted by cyberdelic on November 9, 2008 at 6:02pm

And I'm on Media Temple too. Has anyone figured out what's going on?

sounds like it's time for a support request to MT!!

Posted by zilla on November 9, 2008 at 10:10pm

i'm going to submit this issue though i have NOT seen it in a little while (on grid)

are you fellow MT users on the grid server shared thing?

........................................................................
i love to waste time: http://twitter.com/passingnotes

Any insights

Posted by ecksley on February 27, 2010 at 5:08pm

I'm also on media temple, and have also just encountered an "out of memory" message. Was this ever resolved?

John Gavula | Gavula Design Associates - Strategic Branding

welcome to mediatemple quality

Posted by ajfabb on April 1, 2010 at 6:15pm

I have clients calling me regularly due to this (and other) problems. Currently on hold again.

user warning: Out of memory (Needed 2092896 bytes) query: SELECT * FROM files f INNER JOIN upload r ON f.fid = r.fid WHERE r.vid = 155 ORDER BY r.weight, f.fid in /nfs/c01/h15/mnt/ ... /html/modules/upload/upload.module on line 553

fabbrication.net

Similar incident on Media Temple (gs) platform

Posted by o0 on April 1, 2010 at 7:00pm

I have multiple websites hosted on Media Temple's Grid-Service platform experiencing the same kind of issues. It started just a couple of days ago. The Drupal install has not been updated for a while on these sites. php.ini is set to 99M for the PHP memory limit (MT's default). The "upload.module" and "user.module" seem to be the 2 main module generating the MySQL errors. Media Temple has currently no incident reporting this issue, other than their ongoing exploit problems.

aj fabb, did you get any updates from Media Temple yet?

---
user warning: Out of memory (Needed 2091072 bytes) query: SELECT DISTINCT u.uid, u.name, s.timestamp FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.timestamp >= 1270146662 AND s.uid > 0 ORDER BY s.timestamp DESC in /nfs/c01/h05/mnt/***/domains/***/html/modules/user/user.module on line 762.
---

Try running a repair on all

Posted by ajfabb on April 1, 2010 at 7:49pm

Try running a repair on all your tables (you can access the mysqladmin through the MT account center, choose your DB, click Select All tables at the bottom, and then "with selected do": -> repair.

Otherwise, pay more or go elsewhere I think.

fabbrication.net

mediatemple's reply is that

Posted by ajfabb on April 1, 2010 at 7:47pm

mediatemple's reply is that the GS cannot handle these mysql queries without upgrading to a mysql container (another $20/month).

We tried repairing and optimizing the mysql tables to reduce the overhead but, still, this query is too large. I looked at the tables being joined and they are not very big. Perhaps Drupal should make this code more mysql-friendly:

function upload_load($node) {
$files = array();

if ($node->vid) {
$result = db_query('SELECT * FROM {files} f INNER JOIN {upload} r ON f.fid = r.fid WHERE r.vid = %d ORDER BY r.weight, f.fid', $node->vid);
while ($file = db_fetch_object($result)) {
$files[$file->fid] = $file;
}
}

return $files;
}

fabbrication.net

Thanks for the update ajfabb.

Posted by o0 on April 1, 2010 at 9:11pm

Thanks for the update ajfabb.

I figure that that might have been the issue and I purchased a MySQL Lite container upgrade (for those of you not familiar with this MT-specific feature: this adds a single instance of MySQL server with fully isolated resources and 128MB of memory). After rebooting the container once, the issue was gone.

I'm glad that the issue is resolved. I'm still wondering why the site became unstable in the last few days, as the Drupal install was not modified for at least 1 year (no new modules added, the cron job is running daily to keep the db clean, etc.). As you mentioned earlier, this makes me believe that it's another Media Temple Grid-Service overall issue.

I've been using Media Temple Grid-Service for a while now, and I appreciate their transparency when it comes to reporting incidents on their infrastructure, as well as their adoption of newer hosting technologies at entry-level pricing. But it seems that MT never made their Grid-Service platform reliable enough. I believe I've been patient enough. I've been using Rackspace Cloud service for a while now, and although their cloud-hosting platform (called CloudSites) is not perfect either, it's far more stable and the servers seem to be faster. The CloudSites service is $150/month, but you can host multiple clients/sites on 1 account (it will scale automatically if more CPU/RAM/bandwidth resources are needed). It's a bit similar to an entry-level managed dedicated server. Anyway, I though I would share with the community...

More info on Rackspace Cloud: http://www.rackspacecloud.com/

yep I've moved most of my

Posted by ajfabb on April 1, 2010 at 9:17pm

yep I've moved most of my sites to Rackspaces "cloud servers", which is similar but you have to manage your own server.

That is, I had to install linux, apache, mysql, etc. from scratch and now I have to maintain it. The performance and reliability are an order of magnitude better than MediaTemple's GS service though.

The "cloud sites" service you picked is more like MediaTemple's GS in that it is much easier to manage, from what I gather.

fabbrication.net