Specifically: Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 76 bytes) in /home/proform5/public_html/store/lib/Varien/Data/Tree/Node.php on line 71
Current my catalog is setup like: (we are selling parts for cars)
Root Catalog
Shop Proform
Year
Make
Model
Submodel-----adding these categories causes the error....
...but when I back-page the data is shown in the tree and also reflects in the storefront. Additionally I can associate products without issue.
Can I allocate more memory for the tree in Magento or do I need to get with my server dude? Should I bother since it is still working?
Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 32 bytes) in /home/proform5/public_html/store/lib/Zend/Db/Statement/Pdo.php on line 273
...but Magento is still adding the data.
I’m pretty new to this folks so anything will help.
After speaking with our web hosting service. Our memory is limited to 40m. I have probably 1/20 of our catalog data in… Basically I need a dedicated server. Before I get one, is there anyway to estimate the memory demands of Magento with our complete catalog uploaded?
Check out what I have so far.... I stopped at Audi and need to get all the way to VW.
http://proformdesign.com/store/
(yest the design is weak, function is our focus right now)
You shouldn’t have any serious problems with this error. You can continue to repeat whatever operation it is over and over until the operation is complete and you have no errors (just hit F5). I’ve not seen this with category creation but I have seen this with product importing and URL rewrite refreshing.
For a moderately complicated catalog, you cannot get around this error. You can give PHP 128 megs, or even 256 megs, but you’ll still run out. :-(
Even if you could you would not want to give PHP that much memory. For the admin pages it might be desirable, but there’s no way to segment PHP settings for different portions of an application. The memory limit is designed to keep bad programs from taking memory away from the entire operating system. A 40 meg limit is for each apache process, which means that you could have 255 apache processes each wanting 40 megs of memory at the same time.
I have 100 categories and I can kill around 128 megs of memory in one operation.
Fatal error: Allowed memory size of 131072000 bytes exhausted (tried to allocate 32 bytes) in lib/Varien/Data/Tree/Db.php on line 266
You shouldn’t have any serious problems with this error. You can continue to repeat whatever operation it is over and over until the operation is complete and you have no errors (just hit F5). I’ve not seen this with category creation but I have seen this with product importing and URL rewrite refreshing.
For a moderately complicated catalog, you cannot get around this error. You can give PHP 128 megs, or even 256 megs, but you’ll still run out. :-(
Even if you could you would not want to give PHP that much memory. For the admin pages it might be desirable, but there’s no way to segment PHP settings for different portions of an application. The memory limit is designed to keep bad programs from taking memory away from the entire operating system. A 40 meg limit is for each apache process, which means that you could have 255 apache processes each wanting 40 megs of memory at the same time.
I have 100 categories and I can kill around 128 megs of memory in one operation.
Fatal error: Allowed memory size of 131072000 bytes exhausted (tried to allocate 32 bytes) in lib/Varien/Data/Tree/Db.php on line 266
Now I’m getting the memory errors when I add model information and try to refresh the catalogue rewrites cache.
This is likely a project killer. With a catalogue that spans roughly 20 years, with an average 10 auto manufactures (at least) each year, averaging 6 models and around 3 sub models for each models = a pretty massive catalog, and memory error this early is a problem. In addition to the catalog, we will have about 5,000 products with catalogue association to various sub models spanning several years, so I imagin this is only going to get worse.
It has been fun but it looks like I’m gonna have to pay for something…boo… I will definitely look at magento for small projects in the future and keep an eye on its evolution.
Just to re-iterate here: I’ve only seen these problems on the admin back-end pages, the run-away memory consumption never touches the front end.
I think my catalog of products is pretty close to the size of yours, probably 20-30% smaller, but I re-organized my catalog (thanks to crashtest) and have reduced the number of categories and increased usability by taking advantage of the layered navigation.
I would classify this extreme memory usage as a bug. I’ve been working my butt off to find the root of the problem, but I wouldn’t bet on this behavior sticking around much longer after a 1.0 launch. So, it’s up to you to switch, I don’t envy being in your position with such an important decision to make.
Also, think of it this way. If Mage does 95% of what you want a shopping cart to do, and another solution does 80%, you could throw the extra programming power that you would have to use on a different shopping cart onto better integration tools. I mean, it’s just PHP and MySQL at the end of the day. Someone can whip up some quick scripts to inject your data into the system better than the default back-end screens (I’ve done exactly this for a client).
This is a huge problem for me as well. I’ve got over 50,000 SKUs to import and I’m averaging about 70 before it errors out on me.
Can you show an example of a custom script that would inject the basic product information needed to set up a new product (before worrying about the non-required elements and attributes)??
countryRegions =
Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 41 bytes) in /customers/lins-fashion.com/lins-fashion.com/httpd.www/lib/Varien/Object.php on line 193
the .php file and line number keeps changing when I press F5
and note that this is on the FRONT-END on the Checkout page… Also my database has 1 product for testing :(
I am importing over 9000 products from xml file to the database. I made two changes and it seems it helps. I am not sure if this is the solution but it seems that it worked for me.
1- In admin go to system-cache management and disable all cache.
2- Now I am using linux not windows. Maybe it is enough with the first point!
Hope it will help someone.
I notice that there is a lot of complaints about this as i am experiencing a memory issue myself.
I wonder why I have not heard back from the Magento team members about this at all?
This issue is enough for me to turn away altogether as it becomes a business risk.
Someone please advise!
The only solution I get is the php.ini.
I was told that adding it to all necessary directories will help.
Increase the php.ini to 256M if necessary.
Okay so here is what I did...go to the php.ini and use the following settings:
max_execution_time = 30000 ; Maximum execution time of each script, in seconds
max_input_time = 60000 ; Maximum amount of time each script may spend parsing request data
memory_limit = 128M ; Maximum amount of memory a script may consume (32MB)
Signature
Okay so here is what I did...go to the php.ini and use the following settings:
max_execution_time = 30000 ; Maximum execution time of each script, in seconds
max_input_time = 60000 ; Maximum amount of time each script may spend parsing request data
memory_limit = 128M ; Maximum amount of memory a script may consume (32MB)
Signature
and also, you need add this line in the index.php file of magento:
