0

Is this a caching problem?

“Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 71 bytes) in /var/www/.../lib/Zend/Db/Select.php on line 744 Fatal error: Class 'Mage' not found in /var/www/.../app/code/core/Mage/Core/Model/Mysql4/Session.php on line 92”

Would it be enough to flush the cache or what is the appropriate reaction and why does this happen?

It happens when a user opens a link for his account area

$configNode = Mage::app()->getStore()->isAdmin() ? 'admin/security/session_cookie_lifetime' : 'web/cookie/cookie_lifetime';

Thats the line 92 where it errors out.

5
  • We need more information, can you post the traceback call and also the lines of code where the problem is originated?
    – lloiacono
    Jun 2, 2015 at 7:15
  • I´ve updated the question
    – Klettseb
    Jun 2, 2015 at 7:17
  • You need to crease php memory limit 512M
    – Amit Bera
    Jun 2, 2015 at 7:22
  • But this happens only to a few users ?
    – Klettseb
    Jun 2, 2015 at 7:27
  • The line where a memory allocation error is triggered is only marginally relevant to the problem: you know the problem is before that point and if it's a method that is only requested once in a code path, you can visit all callers and work your way up. In general: look for the two patterns I described, in this case I'm 99% sure it's the collect totals problem. I'll amend answer.
    – user4351
    Jun 2, 2015 at 10:27

2 Answers 2

1

There are a number of possible causes. Cache isn't really on of them. The two primary causes are:

  1. A large collection being read into memory at once.
  2. A nested infinite loop that creates one or more new instances of the same entity.

The first should immediately spark a lightbulb over your head :-) and the fix is to either use the paging functionality for collections, which fetches a large results in chunks. Or one can use the collection iterator.

But it's sometimes less obvious, for example when you've provided a "view all products in this category" page and over time or through an import error this category has become loaded with hundreds or even thousands of products.

The second is a common mistake in many extensions that are part of the totals collection process in the cart. In order to do their work they need some information from the current quote and then request it from the cart. This is incorrect when a flag has been set in the quote that signals Magento that prices may have changed out of band.

The handling of this recalculation is done in the cart _afterLoad, which means the cart has not finished loading. You guessed it, requesting the information from the cart at that point will once again start the loading cycle and creates a new cart instance and any objects that methods create during their collectTotals process.

The only time I've seen cache be a problem in relation to memory is when saving the cache fails and the memory involved creating the information to be cached isn't freed, leading to starvation of memory over time. Still not hitting this error.

This fits the pattern of cache: it should eliminate operations to construct certain objects and just hand you the result. As a rule of thumb, constructing something requires other somethings, and will therefore use more resources including memory.

Update: Here's the case when this happens on checking account view page:

  • When a customer logs in, her old abandoned carts are merged with her current cart.
  • If trigger_recollect is present on one of the old carts (SELECT s.created_at, s.updated_at, s.customer_email FROM sales_flat_quote s LEFT JOIN customer_entity e ON s.customer_id=e.entity_id WHERE s.trigger_recollect=1) this initiates the collect totals.

If you have MultiSafePay 1.x (aka Mage/MSP) installed and use catalog rules, you can be sure you have the problem.

3
  • I guess it is the customer log in and the old abandoned carts. Is there a possibility to make sure this doesn´t happen?
    – Klettseb
    Jun 2, 2015 at 12:15
  • Yes, clean out the quotes. For this specific customer, just delete her old carts, using plain SQL. The periodic cleaning of abandoned carts is a standard feature in Magento and can be configured to a specific time (like 30 days). But...make sure the ON DELETE and ON UPDATE triggers are present on sales_flat_quote and related sales_flat tables. I've seen installations dating from the 1.5 age where these are missing and then you create a whole new mess (read: ghost cart items appearing in quotes or not appearing but price will be in total). When in doubt, use the DB repair tool.
    – user4351
    Jun 2, 2015 at 12:56
  • Of course, the real fix is to fix the extension(s) that generate the bug. All extensions I've seen so far that have this problem, either have an upgrade that fixes it (MultisafePay 2.x) or are open sourced and can be fixed by using the quote provided by the hooks the code is using.
    – user4351
    Jun 2, 2015 at 12:59
0

You can also try to put this on the top of your file:

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

This way you only increase the memory limit when this file is executed, later you can try to find out why is using so much memory and fix it and remove the ini_set.

For more info check this links: http://php.net/manual/en/function.ini-set.php

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.