I recently took a look at a Magento website that was having frequently recurring periods of inaccessibility.

During the initial discussions it was determined that the "outages" were in fact PHP script errors, which in some server configurations are disabled by default, displaying a rather useless blank white screen instead.

You can easily enable error reporting by using a local PHP override either in a php.ini file or, if that won't work, setting PHP flags inside your .htaccess file:

php_flag display_errors on

As soon as the errors were being displayed, the problem was indeed revealed as a PHP script error:

Warning: include_once() [function.include-once]: Unable to allocate memory for pool. in /var/www/vhosts/httpdocs/app/Mage.php on line 49

Whilst not immediately useful, it does at least provide some food for Google in order to begin a search for potential solutions. During this research phase, I actually turned up very little relating to Magento specifically, but there was quite a lot of information in relation to PHP. In many cases, an Apache module known as "APC" kept cropping up. Apache APC ("Alternative PHP Cache") is "a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code.".

A quick check of server options using phpinfo(); confirmed that APC was indeed running on the server.

The Solution: Disable APC

I find the Magento's cache system quite comprehensive, and set-up correctly should provide an adequate caching system/performance boost for your Magento site. If you have alternative thoughts or can offer more information on how APC can benefit a site, I'd welcome your comments.

So, in this case, I decided to disable the APC module for this particular virtual host on the server (this way it's still available for other sites running on the server). Disabling the module is very simple, and easy enough to re-enable if you need to do so in the future. It requires another line added to your .htaccess file:

php_flag apc.cache_by_default Off

You can re-run phpinfo(); again to confirm the APC is disabled correctly – and of course, test the live site to see if it fixes your problem!

There are 8 awesome comments...

1. 

   @JesseLuna - June 13, 2011 at 12:03 am

   Thanks, that helped! I’m still wondering why the messages appeared in the first place though…
   -Jesse
2. 

   k - June 28, 2011 at 8:10 am

   Please… this is not a solution, it’s ignorance. Take the time to learn APC. A good start would be this post: http://stackoverflow.com/questions/3723316/warning-require-once-function-require-once-unable-to-allocate-memory-for-po
3. 

   Dan Luton - June 28, 2011 at 12:51 pm

   K,

   While I agree with your sentiment, the information in the post is still useful in some cases – say, someone who has a shop who can ill afford it to be offline for hours (even days) on end.

   It would also buy some time to correctly rectify the issue whilst keeping the shop online.

   I never said my “solution” was the be-all and end-all, it’s just a solution, and is intended to provide a reason for the error and one potential stop-gap solution.
4. 

   Devesh - September 22, 2011 at 7:05 pm

   Thanks a lot, i have around 4000 users and very active forum, because of these stupid errors filling whole page was distracting my users, and i followed your instructions and Boom, errors are sweeped away…So thanks a lot..
5. 

   sam - November 4, 2011 at 10:41 am

   I agree with K, this really isn’t a very useful post. As you say this is a stop-gap solution that ultimately slows down your system.

   A decent opcode cache such as APC does add a significant performance boost for minimal overhead, particularly for large complicated systems and should be used if possible.

   The reason that was happening is that APC couldn’t find anywhere to put a new cache entry, this is either because you don’t have enough memory allocated to it or the memory that you have allocated is full. There are 2 php.ini entries I changed to solve the same issue:

   1) Increase the size of the cache, we have the ram so this was an option for us.
   apc.shm_size = “64MB”
   2) Add a timeout so that stale cache entries are re-used.
   apc.ttl = “60″;

   restart and done.
6. 

   sam - November 4, 2011 at 10:43 am

   Also here is a link to a benchmark that clearly shows why it’s better not to just turn it off:
   http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html
7. 

   Dan Luton - November 4, 2011 at 10:49 am

   Thanks Sam. I did in fact try to override the PHP config with a local .ini, but the settings didn’t take effect, of course not all hosting solutions allow this.

   It’s great to have alternative potential solutions though – hopefully your comment will help someone out before they have to take more drastic steps!
8. 

   Nicholas Thompson - May 8, 2012 at 2:52 pm

   I also agree that disabling APC is not such a great plan, especially when the fix is pretty much as simple as increasing the apc.shm_size in the apc.ini file. (as per the StackOverflow thread).

Leave a comment: