This post is not about adding memory in php.ini or .htaccess or settings.php in Drupal. You might be getting the Fatal Error because of URL redirects causing infinite loops induced by running database update scripts!
But, here’s the skinny on adding more memory accessible by Drupal. This will depend on your hosting provider and how much they allocate per account – ask them what the max is.
- .htacccess [in the root of your site only]
php_value memory_limit 256M
Find this and increase the RAM.
It might also look like:php_value memory_limit = "256M"
- Add this
ini_set('memory_limit', '256');to your [Drupal 7 root]/sites/default/settings.php file.
Back to the story:
It’s been a year since you looked at your Drupal site and realized that you have some core and other contributed module updates. Drupal tells you to to run some database updates.
STOP WHAT YOU ARE DOING RIGHT NOW!
Part 1
If you are not running these updates on a test environment you may just take your site down and it will stay down until you restore the database, at least.
If you have no choice, you *must* do a database and code update that is easily accessible and convenient to restore. For the code, you could download it your local machine, then use something like Beyond Compare to update only files that changed.
Part 2
You’ve downloaded your Drupal site and run the updates. The site takes a year to do anything and then responds with something like this:
Fatal error: Allowed memory size of 33554432 bytes exhausted ..../includes/cache.inc
That allowed memory size is probably the max value of RAM set in the above settings. Note that the .inc file in this case is cache.inc. With my problem this file file changed every time I reloaded the page and got the fatal error.
Sanity check: this is what worked for me. You, like me, could go down a very long and deep rabbit hole diagnosing this problem. This solution could work for you. If it doesn’t, you will probably need to start turning off modules until it does, then figure out how to get your site back to normal. Good luck.
My problem was infinite loops causing a race condition. After reading a hundred pages about different fatal errors and most of them pointing to RAM configs, I finally found this.
Before I found that I also did this (note that I have access to my MySQL server, unlike many):
MySQL Server:
mysql> SHOW VARIABLES LIKE "general_log%";
Look at log info. You will find the path and status of the logs here.
mysql> SET GLOBAL general_log = 'OFF';
Default is off.
mysql> SET GLOBAL general_log = 'ON';
Once it is on, keep an eye on it! It will get very large, very quickly. No, you can’t log a single db.
mysql> SHOW FULL PROCESSLIST;
Handy for seeing processes.
Back to the story again:
So, I ran the SQL code in the article (please read it – someone else did the work that I am writing about):
SELECT r.rid, r.language, r.source, r.redirect FROM redirect r INNER JOIN url_alias u ON r.source = u.alias AND r.redirect = u.source AND r.language = u.language;
I then deleted the duplicates:
DELETE r FROM redirect r INNER JOIN url_alias u ON r.source = u.alias AND r.redirect = u.source AND r.language = u.language;
Voila! Problem solved!