Last updated April 10, 2014. Created by dman on July 29, 2006.
Edited by charlie charles, erikwebb, adTumbler, Christopher Jam.... Log in to edit this page.

That indicates that Drupal needed more memory than PHP was allowed to give it.

Drupal 7

  • Memory increase to 128M:
    (This has worked every-time; and used to always work for D6 as well)

    Create a new file php.ini, and add the code...
    php_value memory_limit = "128M"
    and put that file in your Drupal 7 (or D6) root folder.
  • If you need more than 128M:

    Add the line
    ini_set('memory_limit', '512M');
    to your [Drupal 7 root]/sites/default/settings.php file.

    I have yet to need this much memory, but I did achieve
    a memory increase to 512M using this slightly more complicated
    process that involved temporarily changing the permission level
    for that file.

End Drupal 7

===================

Increase PHP memory limit

Increase PHP's memory limit, e.g. to increase it to 32M you could try adding:

  • memory_limit = 32M to your server's main php.ini file (recommended, if you have access)
  • memory_limit = 32M to a php.ini file in the Drupal root
  • ini_set('memory_limit', '32M'); in your sites/default/settings.php file
  • php_value memory_limit 32M in your .htaccess file in the Drupal root

You can also try Drupal tweaks module.

On most hosts not all of the above methods will work, and some shared hosts will not allow any modification of your capacity at all. Slightly more instructions on increasing PHP memory on your server in the installation guide.

Depending on the amount of modules you have enabled and their 'impact' on the site you may need to increase the memory_limit even more (sometimes to 32 MB or more). Image processing often takes a lot of memory, as can working with any large files. Experiment with what memory value works for your needs.

Clearly, if your error was memory size of 16777216 bytes exhausted (16M) in the first place, then you are going to have to be bumping the limit up even higher than that. Do the binary thing and double it to 32M.

You may need to restart your server before the php.ini settings take effect.

Note: Do not just set an arbitrarily high number just to avoid this potential problem - it may limit your ability to have multiple simultaneous connections run efficiently, and simultaneous connections are important on web servers.

Reducing Memory Usage

There is no way to know how many or what combination of modules will put any one site over their memory limit. Every module uses a different amount of memory. Core requires memory by itself and requirements for core alone should be understood. see: http://drupal.org/requirements

A frequent example of this error occurs when too much content is retrieved in a single request. This could include using node_load() on a large number of nodes, loading an entire file into a variable (rather than iterating over the file), or creating a large number of dynamic elements on a single page, such as multiple Views blocks or Panels.

1. Views (can) use a lot of memory

Some Views (and Panels and CTools and everything merlinofchaos touches with his mighty, mighty fingers), but it's possible to create configurations with multiple relationships that use a lot of memory. If you disable your Views and the memory issue goes away, it's likely a badly-constructed View causing the issue.

What to do if it is a View, and you really need that View to work? Try putting it into code (Via Bulk Exporter or Features; see below. I've hand-coded Views-like functionality in order to improve performance with very little success) for a start. Another thought is to redo the View a different way -- if ultimately what you're getting at is taxonomy terms, make sure the type of View is a Taxonomy View when creating it; don't create a Content View that uses relationships to get at taxonomy terms.

Could also be worth mentioning here that Panels also supposedly uses a lot of memory -- I haven't really benchmarked it so can't confirm this.

2. Moving stuff from database into code is a very good practice

It took me several Drupal sites to realize this, but keeping everything that's created via a UI in the database (Views and Panels configurations especially) is a Drupal worst practice. Why? It increases load on the database and cannot be version controlled. The first point is particularly problematic in terms of memory usage -- instead of just loading the content from the View from database, the site must also load the view components itself. This is exacerbated by how Drupal uses tables: by abstracting everything to the nth degree, each bit of Drupal's functionality uses a new table, resulting in some requests joining a bajillion tables together. This gives Computer Science people hernias (caveat: link is silly), but can't really be avoided with a piece of software as modular and user-friendly as Drupal is.

The solution? Use Bulk Exporter (Included with CTools) or Features to package up bits of code currently residing in the database as module code.

3. Themes can also eat memory

Does your theme have a lot of template files (I.e., files in themename/templates/)? If so, memory is consumed each time one of those files is loaded. If you're creating templates specifically to suppress bits of Drupal from being displayed, try either:

  1. Changing permissions so that bit doesn't show up for specific non-admin user roles.
  2. Using CSS to hide elements.

The first choice is obviously what you want to do for stuff affecting security -- you don't want to use CSS to hide an "edit" button for certain users, only to have them then unhide it via Firebug or whatever.

4. Don't go overboard on contrib modules

While sometimes a site needs a lot of contrib modules, don't go overboard. Each enabled (note: enabled. Disabled modules don't use any memory) module uses memory. This is a bit obvious, but worth noting regardless.

5. The VPS is (sometimes) a lie

In my experience, some unscrupulous hosting companies love trying to push Drupal sites to VPS servers -- they're more expensive and it frees up shared hosting space for ever-more WordPress websites. The situation is worsened by the fact that webhosts often don't advertise (Or even willingly tell you if asked) what the upper memory limit is for shared hosting.

Alas, often if a site isn't under heavy traffic and is still crashing, the issue likely has something more to do with Drupal's configuration than anything else. Pushing a user to VPS just muddies the waters and adds more variables to deal with (Is it the webserver config? PHP config? VPS guest config? VPS host config, even?).

6. When all else fails, clone to localhost and beat it with a stick

This is a big reason why people use the dev-staging-production methodology with version control -- when all else fails, you can do a DB dump, git clone the site to a local testing server and then royally mess up the site on the testing server without worrying about actually breaking anything on the production server.

For memory issues, this generally means disabling modules one by one until the one causing the issue is exposed. It can also point to webhost-related issues -- if the site runs perfectly fine on a local install with memory set to something reasonable like 128MB, then you know your webhost is on crack.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

Running 1and1 Developer Server (Not Dedicated)

Okay, did the above and it failed.
Forget about the memory limits in the php.ini and .htaccess file. Just use the above line
ini_set('memory_limit', '16M'); in settings.php

This worked for me.

Also, note that you should manually setup your db information as specified in step 19 of this page:
http://www.ehow.com/how_4858748_install-drupal-servers.html

You should have a php.ini file with the following in it uploaded to your root where the domain is pointed for your site.
register_globals = off;

.htaccess should have
"ON" capitalized for "RewriteEngine on" as well at this line at the top
AddType x-mapp-php5 .php

MEMORY LIMIT ON DREAMHOST PRIVATE SERVER PS ?

Hello,

I set

ini_set('memory_limit', '150M');

in your sites/default/settings.php file

because 100M was not working anymore for a very large website, do you know what is the limit on DREAMHOST servers ?

Can you think of any problem if i set the limit to 200 or more to be safe in the future ?

Thanks.

Same thing worked for me.
Except I messed-up by recycling an old settings.php file with old user pass and db settings robotically written-in to it. During the trial and error, they didn't work for the next installation until I learned to edit the settings.php file by hand with each new installation. There are other reasons for the same error message on this thread - usually setting up a database without the wizard, or whatever allows user privilages I think - anyway the thread is here http://drupal.org/node/1157406

http://www.veganline.com - old shop
http://veg-buildlog.blogspot.com - blog about trying to replace it

Hi,

I noticed that once you have this problem, it is difficult to pinpoint and solve. As memory is mostly fixed with hosting partners, increasing it is more a workaround then solution.

How can one discover what is the cause and where the faulty code could be.

Any experience on tracking down the memory usage and optimizing it would be helpfull.

Joel Box - Mondial-IT

You misunderstand the problem. It's not a case of any one bit of faulty code. It's a case of aggregate capacity.
If you order a meal that costs $20 and you only have $16 to pay for it. There is a problem. There is no "work-around". It's not the "fault" of the sauce or the lettuce.

You just need to get hold of $20. Or choose to do without the entree.

If you are interested in debugging, the devel.module provides a number of tools that help trace performance. You can install XDebug for memory profiling if you like. Also there has been heaps of work on Drupal performance if you want to look.
Your host also has the ability to provide you with the Apache and PHP logs that will pinpoint exactly what was happening when a memory failure occurred.

Note that even if you find the point in the code where the memory ran out, the point of failure is almost never the cause of memory issues. Memory issues mean that something in the process somewhere before the failure point needed to use more memory than you chose to provide it. And the point of failure may change radically depending on the content it is running over.
A memory blowout is a result of the amount of work done, the size of the content and the complexity of the page. It could be that rendering a complex view with 6 items takes 15Mb and rendering it with 8 items takes 17Mb and causes a memory fail when processing comment.module.
It's not the fault of the extra two items, it's not the fault of comment.module.
It's that you need an appropriate amount of capacity.

So yes, it's tricky to pinpoint. But use the tools and you can.

Of course memory is used in many modules and processes, however runaway memory and not returned memory only by ill-behaving code. It is quite clear to the developer what size an array, a form or table is and drupal offers ampel options to savely store large data into the database. In the modules you see some using a few hundred k, while an import module takes a full 8Megs. That sort of narrows down where to optimize.

My problem is specifically with modules where code is not returning or decreasing memory (use of globals, statics and arraycopies.

Perhaps sometime I will have a go at enhancing the profiler and "swap" memory close to limit to disk...

Kind regards.

Joel Box - Mondial-IT

note that there can be memory bottlenecks other than PHP.

working on a WiredTree VPS account recently, it took me awhile to figure out that Apache's RLimitMEM directive was the culprit rather than PHP's memory_limit. presumably this could be fixed by altering either httpd.conf or via an .htaccess file.

there are many discussions of these problems on d.o, but it can be hard to find them. this comment in particular, was helpful for me.

I just spent two days wading through the mystery quagmire that is the memory limit files for drupal. After trying to modify and change the htaacess and the setting.php file I finally got fed up and called the provider. They told me to make a text file named php.ini and drop in this snippet of code php_value memory_limit 200M . This works for a greengeeks hosted account. I hope that this can save someone valuable time.

Thanks for the info. This was most helpful at eliminating the memory limit, although I'm troubleshooting a permissions error on the file that puts things into Safe Mode. Did you run into any permissions problems with access to the file or the TMP files?

(This solution had always worked for Drupal 6 as well,
back when I used to use D6.)

By default, Drupal 7 at my online webhost allocates 64M (megabytes) of memory
and so if you are experiencing this error, you need to increase that limit to
128M.

I always get this error after installing several additional modules (Contributed modules)
and the solution that always works is...

  1. Open a text file editor. (Eg. WordPad, NotePad, etc.)
  2. Add the text
    php_value memory_limit = "128M"
  3. Save the file with the file-name
    php.ini
    • It is critical that this file be saved with the name php.ini
      because in the case of your using the Microsoft windows operating system
      the file might be saved as "php.ini.txt" without your being aware of that fact.

      That is the default condition with using NotePad or WordPad with Windows XP,
      for example, because of the default setting...
      'Tools' > 'Folder settings' > tab: 'View' >
      check-box 'Hide extensions for known file types'...
      and is evidenced if you see the file listed as simply "php".

      Feel free to un-check that folder options setting check-box,
      and click the bottom button 'OK',
      and you will there-after always see the actual file extensions
      for all the files on your system.

  4. Place the file php.ini into the root folder (also known as 'root directory')
    so that it is in the directory that also containing folders
    'includes', 'misc', 'modules', 'profiles', 'scripts', etc.

The problem should be over immediately.

Additional notes:

  • You can see the amount of memory you are being allowed by going to
    'Reports' > 'Status report'; and scrolling down to "PHP memory limit".
    It should read '128M' if you have followed the above steps.
  • Increasing the php.ini code from "128M" to "256M" did not change my
    status report amount, and it still reads "128M".
  • Decreasing the php.ini code from "128M" to "64M" also did not change my
    status report amount back to "64M", and it still remains "128M";
    although I did change the php.ini code back to "128M".

If you need more than 128M, the solution is slightly more complicated.

See the comment below, "Drupal 7 memory increase to more than 128M"

"All the best; intended."
- Chris
___

Drupal 8 is great.

Re: Dupal 9,000
Three-minute Video on the problem
of technology out-pacing users.
http://great-grandma.com/gill_bates-dead_at_42/index.html

Drupal 7: If you need more than 128M, then add the line
ini_set('memory_limit', '512M');
to your [Drupal 7 root]/sites/default/settings.php file.

I have yet to need this much memory, but I did achieve
a memory increase to 512M using this slightly more complicated
process that involved temporarily changing the permission level
for that file at my online webhost.

The following applies to an online installation,
but if your installation is "local" on your computer
just follow the instructions below and ignore the extra steps
required for the online installation.

I have not tried the Local approach, but I assume
it would work equally well.

  1. Download a copy of the file "settings.php"
    (if you do not already have a copy on your computer)
    that is located at
    [Drupal 7 root]/sites/default/settings.php
  2. Open the file with your favorite text editor
    (Eg. WordPad, NotePad, etc.).
  3. Add a line of code on a line of its own
    at the bottom of that file...
    ini_set('memory_limit', '512M');
  4. 'Save' the file.
  5. Change the file permission level of the settings.php
    file on your server from "0444" to "0777";
    otherwise you will not be able to over-write it with
    the newly saved file you have on your computer.

    In the case of my Drupal 7 installation being on my webhost...
    1. I go to my online webhost account's control panel (CPanel)
    2. Click on the link for the 'File Manager'.
    3. Navigate to the file [Drupal 7 root]/sites/default/settings.php
    4. Change the file permission from 0444 to 0777.

      This might take some poking around for you to figure
      how to do it, but it should be easy enough once you
      find the right thing to click.

      In my case, double-clicking on the "0444" allowed me
      to edit the number right there, although
      you should also be able to change the permission number
      by highlighting the file, and clicking a button or link
      called "Change Permissions"; or similar.

  6. Replace the Drupal 7 settings.php file with the one you modified
    by an upload of the file settings.php that you have on your computer
    to the proper location on your webhost server
    using either your control panel (CPanel)
    or your FTP program.
  7. Change the permission level for the file back to 0444

Additional notes:

  • You can see the amount of memory you are being allowed by going to
    'Reports' > 'Status report'; and scrolling down to "PHP memory limit".

    It should read '512M' if you have followed the above steps.
  • Replacing the modified settings.php file on my website
    with a copy of the original settings.php file
    returned the "PHP memory limit" to what it had been before.
  • I have read that "Restarting the server" is required for local installations
    although I have no experience with that.

All the best.

"All the best; intended."
- Chris
___

Drupal 8 is great.

Re: Dupal 9,000
Three-minute Video on the problem
of technology out-pacing users.
http://great-grandma.com/gill_bates-dead_at_42/index.html

Working with Greengeeks, Drupal 7.2, I was regularly receiving memory warnings when loading or activating modules. The result was that several modules were only partly activated.
The php.ini solution to add memory brought a white screen up, so I quickly removed that file.
The settings.php solution worked fine.
I'm sorry, I'm not geeky enough to work out why the php.ini solution failed, so this is just a warning; with some hosts, it doesn't work!

Hi. I am having touble with this message: Warning: move_uploaded_file() [function.move-uploaded-file]: Unable to access temporary://small.jpg in file_save_upload(
I think it is to do with my memory limit. I have already increased to 128m and now with pics I am having this problem. I'll looked up the posts on the error message and they have not helped. I'd like to increase to 512m to see if it will help but your suggestion hasn't worked for me. Any other ideas would be valuable.

All,
There are 2 ways of running php: As an apache module or as a cgi. If your host runs php as an apache module, adding your own php.ini will not work. *Most* web hosts are running php as a cgi. If you are running Apache locally on your machine or you have access to the main server php.ini file, you can change the memory limit there. That does, however, require restarting Apache as mentioned above. Most shared hosts will not allow you do this, which is why using the settings.php method is easier. That changes the memory limit "on the fly".

In Linux, the command is typically "/etc/init.d/httpd restart" ( use apache instead of httpd if you're on Ubuntu ). Some systems may also conveniently support this command "service httpd restart" (again, replace with apache if you're on ubuntu).

On cpanel if you have whm access you can restart apache from the services restart menu.

On Xxamp you can restart the services from the control panel tray.

I'm not sure how to restart IIS.

Hope this helps.

This absolutely worked for me, THANK YOU.

I tinkered with all the previous adjustments to php.ihi and such, glad I found you solution!

Hosted at: JustHost.com

Hi,

I was reading all the topic, I try to both way, adding at setting.php

ini_set('memory_limit', '512M');

or creating php.ini and add php_value memory_limit = "512M"

but sill give to me

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 39 bytes) in /membri/macettiandrea/blogViajes/modules/simplehtmldom/simplehtmldom/simple_html_dom.php on line 93

I cannot check in status report php used because apper just the error, Can i just delete the last module that I added? I don't think is good solution but I don't know how to solve the problem...

I'm not very expert of drupal, can you suggest to me how to solve it?

Thank you very much

I did this but the limit remained at 128M on my 'Reports' > 'Status report' page.

Is it possible that the shared hosting is blocking that to 128M even if I change the settings.php file?
My shared hosting is keliweb.com

Please Note that my instructions above, Drupal 7 "Fatal error: Allowed memory size of ..."
for file [drupal-root]/php.ini assume that you do not already have a
[drupal-root]/php.ini file
; which is why the instructions tell you to create the file.

If you already have a php.ini file, then you will want to add
php_value memory_limit = "128M"
to your already existing file.

(on a line of its own; at the bottom)

===

The fact is, however, that with my online hosting account at BlueHost
all I need is the method described in
'Drupal 7 memory increase to more than 128M'
for file [drupal-root]/sites/default/settings.php

Add a line of code on a line of its own
at the bottom of that file...
ini_set('memory_limit', '512M');

It is still necessary that I temporarily change the 'permission' level
for the settings.php file on my website
from level 0444 to 0777.
(I only know how to do this with my webhost account's CPanel - Control Panel)

Then I can successfully overwrite the file on my website using FTP--
but I can Not overwrite it by uploading from my CPanel.

Do not forget to change the file permission back to 0444.

"All the best; intended."
- Chris
___

Drupal 8 is great.

Re: Dupal 9,000
Three-minute Video on the problem
of technology out-pacing users.
http://great-grandma.com/gill_bates-dead_at_42/index.html

New php.ini solution worked in the root dir. Thanks a bunch!

Drupal Themer

I ve got the same problem with the memory
once the error is hint of includes.php
other time with many other modules
but I hope this time will stay ok since i ve fixed the memory to :512M
for :
HTACCESS
SETTINGS.PHP
PHP.INI
thanks

So after hacking around for hours i finally found a solution.
1- Deleted "everything".
2- created a php.ini file with the following text

memory_limit = 512M
extension=pdo.so
extension=pdo_sqlite.so
extension=sqlite.so
extension=pdo_mysql.so

4 Did "not edit" htaccess, settings .php or defaultsettings php
5 installed drupall 7.7 as usual and wallah php memory was set.

What I found that worked for increasing PHP memory for D7 & D6 to 128MB
at my online websites (bluehost.com) was the php.ini solution outlined in...
Drupal 7 "Fatal error: Allowed memory size of ..."
http://drupal.org/node/76156#comment-4582924

To my knowledge, all you would have had to put in your php.ini file was
php_value memory_limit = "128M"

But I see that the multiple lines of code you used in your php.ini file
are addressed at... Increase PHP memory limit
http://drupal.org/node/207036

To my knowledge, increasing the 128 to either 256, or 512
does not cause problems, but it gives me only 128MB of memory
and that is the limit of php.ini per my experience.

I am curious if you are using D7, and
if you did in fact achieve 512MB with the php.ini file using
memory_limit = 512M.

You can see the amount of memory you are being allowed by going to
'Reports' > 'Status report'; and scrolling down to "PHP memory limit".

===

And, by the way, although I have yet to need more than 128MB yet, I did successfully get
512MB using the process delineated in the comment above ...

"Drupal 7 memory increase to more than 128M"
http://drupal.org/node/76156#comment-4583384

by Adding the line
ini_set('memory_limit', '512M');
to the very bottom of the [Drupal 7 root]/sites/default/settings.php file.

I found it interesting that the setting.php solution
was necessary according to the comment above....
"Why the php.ini solution doesn't work for some users"
http://drupal.org/node/76156#comment-4761114

(I have never tried the settings.php file memory increase hack on D6
since I have not been back to D6 since finding that solution)

===

DAMP seems to run faster on my computer
with the php.ini memory solution file thrown into my D7 root
but, .. I don't really know.

"All the best; intended."
- Chris
___

Drupal 8 is great.

Re: Dupal 9,000
Three-minute Video on the problem
of technology out-pacing users.
http://great-grandma.com/gill_bates-dead_at_42/index.html

just to confirm that adding ArchDoomBringer's code from the post above has fixed the pdo problem I was having. Thanks.

cheers,
allanx
perth - western australia
---
web design | development | maintenance: http://radicalhack.com

Thank a bunch, saved me a lot of time with this!
Danny

--
http://roadsignsdirect.co.uk

Instructions in german / deutsche Anleitung:

http://shajkovci.net/node/11

I tried to create new php.ini, I also tried to add that line into settings.php. In Status report the PHP memory limit says 512.

And I'm still getting the Fatal error, almost every time after running update.php.

Any idea please?

If you have APC turned on, usually this indicates that the PHP code caching that APC does is full. In that case, you need to update the APC memory *not* necessarily the PHP memory. Make sense? APC usually has its own config file.

If you are on the shared host and you configured correctly the php.ini for higher memory_limit then the solution is very simple you just need to copy the 'correct' php.ini to the installation folder of drush ; and drush will pick it up by default the next time it run , more details here.

Add the php.ini file at the root worked perfectly!! Thank you!

Took onboard all the comments and I found this worked:

(Hosting with5quidhost)

Did this first......

Posted by Christopher Jam... on June 10, 2011 at 1:31am

1. Open a text file editor. (Eg. WordPad, NotePad, etc.)
2. Add the text
php_value memory_limit = "128M"
3. Save the file with the file-name
php.ini
*

It is critical that this file be saved with the name php.ini
because in the case of your using the Microsoft windows operating system
the file might be saved as "php.ini.txt" without your being aware of that fact.

That is the default condition with using NotePad or WordPad with Windows XP,
for example, because of the default setting...
'Tools' > 'Folder settings' > tab: 'View' >
check-box 'Hide extensions for known file types'...
and is evidenced if you see the file listed as simply "php".

Feel free to un-check that folder options setting check-box,
and click the bottom button 'OK',
and you will there-after always see the actual file extensions
for all the files on your system.
4. Place the file php.ini into the root folder (also known as 'root directory')
so that it is in the directory that also containing folders
'includes', 'misc', 'modules', 'profiles', 'scripts', etc.

Then this.....

In settings.php I added this line: ini_set('memory_limit', '128M');

/**
* PHP settings:
*
* To see what PHP settings are possible, including whether they can be set at
* runtime (by using ini_set()), read the PHP documentation:
* http://www.php.net/manual/en/ini.list.php
* See drupal_initialize_variables() in includes/bootstrap.inc for required
* runtime settings and the .htaccess file for non-runtime settings. Settings
* defined there should not be duplicated here so as to avoid conflict issues.
*/
ini_set('memory_limit', '128M');

Bobs your uncle, fannys your aunt! It worked.

I had slow performance issues with Drupal 7 and increased the memory limit setting in php.ini but Drupal remained slow and thought there was some other issue that I had not traced.
Just today I got an error message from PHP debugging that I had exceeded the memory limit of 128MB.
I then discovered on this posting there is a specific setting to make Drupal 7 increase the memory limit which I then added as a parameter as suggested. The exceeded memory limit message disappeared.

I am running a dedicated server and php is not being run as CGI.

So why is Drupal 7 ignoring the php.ini setting?

What worked for me after much stress was a combination of the advice given in the tut and above comments:

Adding ini_set('memory_limit', '512M'); to the php settings section of my settings.php file that lives in the sites/defaults/
and php_value memory_limit = "512M" to my php.ini file that lives in the root folder of my drupal .

Only changing the php.ini wasn't working. It only worked when I made both the above changes. This is on a drupal 7.14 website.

www.shekinahinvestlimited.com | www.malawianbiz.com
Website Design & Development | Online Marketing | Consultation

If you have a host that allows you to define php.ini settings in your site folder, that's cool, but it may not be the norm (it's certainly not the default).
Can you please name your hosting company here to provide help for other customers in the same situation?
Your solution - though it's good that it worked - applies to your situation (and *maybe* others)

Like I stated in this comment making the changes in both my drupal site's settings.php and my php.ini (that lives in the root) was what fixed it for me.

My host is goDaddy (economy web-hosting plan), running on a linux server, using PHP5 and they provide a custom php.ini in the root of my hosting space with the economy package. This is a shared hosting service.

www.shekinahinvestlimited.com | www.malawianbiz.com
Website Design & Development | Online Marketing | Consultation

...after wasting an entire evening.

putting it in both php.ini (512M) and in settings.php -- both places, like you say in your post. Oddly, I had migrated this localhost site from one machine to another (faster) machine and then these problems cropped up.

I wish these details were posted in ONE prominent place on drupal.org, all together, and at the beginning of "installing Drupal" so we wouldn't constantly run into brick walls.

Thanks to everyone for posting your solutions here, and good luck if you're still having problems with this.

Dan

p.s. My localhost site is much faster now too!

Hi All,

I come around this issue couple of times and Thanks for drupal folks around, i increase the memory and resolve it.
My Question is does it affect anywhere else i mean in stability, performance or security factors??
And what is the max limit till we can extend or ways to reduce the redundant usage of memory.

Thanks again.
Happy Drupaling

Im so fed Up now.
This issue has returned but this time..nothing and i mean nothing will change the php memory limit from 96Mb.
Ive deleted everything multiple times, deleted the database multiple times..tried every combination of editing verios files with php limit and ini but still nothing...please please please someone please help me to set the php limit on install or update.

PS my site is totally ruined now

PPS i just discovered that my host provider has put a cap of 96mb php and that is why these solutions wouldnt work this time.

if anyone has a service provider maybe they could leave me alink..cheers in advance.

The 'Shared Hosting Providers' drupal.org page lists webhosts that are compatible with Drupal; and the links on that page benefit drupal.org as well.

For my part, I have been happily using BlueHost for years. See their link on the above page.
- When signing up for a Bluehost hosting account via the link on the above listed page, Bluehost will donate the entire hosting fee back to Drupal.org.
- Unlimited Bandwidth.
- Unlimited Storage. (For files linked on pages)
- 50 Databases. (Enough for 50 Drupal sites)
- SimpleScripts automated (essentially 'one-click') installation of D6 or D7.
- Just now, using the [d7-root]/site/default/settings.php hack instructions above
Drupal 7 memory increase to more than 128M,
and instead of using '512M', I used
ini_set('memory_limit', '1024M');
and now my 'Status report' page at [d7-root]/admin/reports/status
shows "PHP memory limit.....1024M".

: o )

Good luck. All the best; intended.

- chris

"All the best; intended."
- Chris
___

Drupal 8 is great.

Re: Dupal 9,000
Three-minute Video on the problem
of technology out-pacing users.
http://great-grandma.com/gill_bates-dead_at_42/index.html

Thanks a lot!

I am using Hostagor and new modules never worked because of the limited 64MB failed allocation size. I set the memory to 128mb and every new module I throw works!

All I did was to put the following code on the 2nd line of settings.php
ini_set('memory_limit', '128M');

:D

We are using Dreamhost and this solution worked to fix our Drush 5.7 error after our Drush update.
Fatal error: Allowed memory size of 94371840 bytes exhausted

The key is really to put the code on the 2nd line of settings.php

Hi :)

i am using lhosting.info hosting and it seems hosting doesn't allow to increase php memery limit. It stays 48M. No php.ini changes, neither setings.php changes don't work.
Usually refreshing page with that error helps, but now i can't do anything.
My site says "Fatal error: Allowed memory size of 50331648 bytes exhausted (tried to allocate 101 bytes) in /home/vol9/lhosting.info/ih_11432786/htdocs/includes/database/database.inc on line 718". How can i stop allocating of bytes, or come back one step, or what? I can't reach admin section, nothing is working - just that error. HELP, please!!!!!

If you can't increase memory at all, you will have to do with reduced functionality. There is no way around that. Bigger sites need bigger memory.

To recover access to your site, the only thing to do is disable modules until it works again.
drush would help with that, but you can also do it directly in the database : edit the 'system' table and set 'status' to 0 on some optional modules.

UPDATE system SET status = 0 WHERE name='views';

Running a complex site (250 contribs), I sometimes get a php memory allocation error when saving the module page, it always succeed the next time.

Solring in drupal.org about this, I notice that people generally discuss about 32 vs 64 Mb - letting me think that something might be wrong in my site : I have 1G php memory allocation and 512M of apc_shm_size used at 40% ?

Shall I reasonably still increase this value ?

Thanks

JV

Heck no. 1GB mem for one PHP process on a config screen is no longer a scaling issue or a "straw that breaks the camels back".

It's (almost certainly) possible to pin this on bad or inefficient code, a memory leak or something recursive.
Though 250 contribs is of course mad, there must be either just one of them or a specific combination to blame.

On the module screen, the most expensive actions are clearing and rebuilding the caches. Every module is loaded, every function indexed, and every menu item rebuilt. I can't guess *what* the trigger for you may be, but I've only ever found it necessary to push mem up or over 256M when explicitly running huge batch processes that tried to work with thousands of nodes or terms simultaneously.
What you've got is an indicator that something else may be not right.

Thanks for the insightful response.
I disabled 30 modules that I did not need anymore and could reduce memory_limit to 256M
I also noticed that the server memory kept increasing at a point I had to reboot once a week. One more of these modules might be buggy...

JV

When trying to rebuild xmlsitemap via `drush xmlsitemap-rebuild` on a large site, I got php memory size issues even with 512MB. Running it via UI worked well though and we are going to use that for a few more large sites for now.

I recently updated a drupal 6.x website and immediately started getting this message:

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 336016 bytes) in /home/sitename/public_html/sites/all/modules/views/views.module on line 563

Luckily I had an older version of the site with the old htaccess file and found this line at the bottom of the file, which I added to the new htaccess file and got our site back online.

# $Id: .htaccess,v 1.90.2.3 2008/12/10 20:04:08 goba Exp $
php_value memory_limit 256M

mikev

After hours searching and reading I found this post and it was a delight that someone really took the time to write down where and what to change not only vague snippets and posts of php but no exact place where to put it and find it.

Thanks a lot!!! Saved my day. After my website crashed and got it fixed because of faulty comments, this one is great. Safed me.

It worked just simply to insert the php.ini file nothing more!

I had to import big junks of data to a new website via csv with feeds and the site kept crashing and told me the same error as above now it works and the first things are on the server already.

For other Dreamhost users read also this one: http://wiki.dreamhost.com/PHP.ini

Cheers!

While I was hesitant and not patient at the same time, after changing the memory in the settings.php, the process continued. It would drop with the same error on a different area and I refreshed and it went through. Took about 5 times for me to refresh past the errors and I was in.

Happy Coding ! ! !

http://restechsys.com