suPHP Cannot Allocate Memory (constantly happening)

[NuttyBunny]

Hi everyone.

 

My sister put a Prestashop store on some hosting server, and it seemed to work fine back in February.  Last week she tried to modify some products, but it became impossible because of the Save spinning disabled button.

I did my research and found out that the hosting server is denying some of the last requests because we're running low on memory for our user.

I set the max_memory value to 64M, which I saw is the recommended value on the installation page, but I still have Cannot Allocate Memory errors in two or three tabs in the Product admin section.

The server uses suPHP, which in my opinion sucks because it goes back all the way to the CGI times, but that's what we can afford at the moment.

I found a temporary solution on the net, which implied modifying template files to remove the disabled state from the buttons, of course, with the possibility of getting errors from the non-loading tabs. Apparently that can be fixed by reopening the offending tabs, but it's not working reliably.

 

The question is, is there a way to load the tabs in a sequential manner rather than load them all at the same time? I think that would solve a lot of problems because instead of spawning 11 64M processes in a limited 1G mem environment, we could get away with 2 or 3 processes.  I don't mind the waiting time.  I truly hope this already has been implemented and is hidden on some obscure setting so someone can just come up and tell me.

 

By the way, No, I can't rise the memory limit.

 

Thanks everyone for your time.

[selectshop.at]

In this case, cause it is a server problem and you better should search for another provider in this case, you can also use Prestashop Cloud with the known restrictions it has, but it works and it is free hosting.

 

Restrictions are: you cannot move without paid service to an own hosted service, you cannot install free addons (only the one of paid addons site you can use).

 

If you can live with this, than you can run your shop without any problems. And no, you cannot load it by sequential manner. How you pretend to manage by this way (One script loading other scripts, so cascade)?  If first script can't be loaded, the subsequent one will not load too...

 

The other possibility is to disable suPHP and use fast-cgi with a cache module for more speed. But I don't think you can manage this on cheap webspace.

BTW: which memory limit is set on the server ? Prestashop will not run under 128M (PS 1.5), better is 256M and for PS 1.6. 512M

[tuk66]

64M is recommended memory and it is not enough in some cases. Everything depends on your modules and number of products (in simplicity).

[selectshop.at]

64M is recommended memory and it is not enough in some cases.

Sorry, but this recommendation never was the real scenario for shops in production. I for several times asked Prestashop Team to revise this point, but they never care. 128M is the min, if you are in production, and the bigger the shop version, bigger the memory limit.

[NuttyBunny]

In this case, cause it is a server problem and you better should search for another provider in this case, you can also use Prestashop Cloud with the known restrictions it has, but it works and it is free hosting.

 

Restrictions are: you cannot move without paid service to an own hosted service, you cannot install free addons (only the one of paid addons site you can use).

 

If you can live with this, than you can run your shop without any problems. And no, you cannot load it by sequential manner. How you pretend to manage by this way (One script loading other scripts, so cascade)?  If first script can't be loaded, the subsequent one will not load too...

 

The other possibility is to disable suPHP and use fast-cgi with a cache module for more speed. But I don't think you can manage this on cheap webspace.

BTW: which memory limit is set on the server ? Prestashop will not run under 128M (PS 1.5), better is 256M and for PS 1.6. 512M

 

Yeah, the Prestashop Cloud service seems nice, and the shop is fairly standard. We didn't even bother to modify the templates or anything else... (well, yes, some)

 

The cascading/serial scripting was something I was thinking with the hopes of not creating the 10 simultaneous processes, maybe wait for some to exit first, I don't know.

 

I can't use fast-cgi or anything else, it's a cheap hosting, I can't change anything. 

 

Thanks for your help.  In the end we managed to work this out by disabling the disabled buttons (e.g. always ready to save), and to avoid the error we were getting when saving, we had to switch to the non-loading tabs every time we did a change.  Not the worst thing, but it worked in the end.

 

A solution to this (if you want to help people with low-memory hosts) can be:

Enable the save buttons after all the tabs have loaded.  I know this is theoretically how it works, but if a tab gets a 500 error, the buttons won't be enabled ever, even if you go to the tab and it reloads itself. A nice thing should be that, in the event of a (or several) 500 error, the user could go and load the tab, and when all the tabs are loaded by hand, the buttons get enabled.

 

Thanks for your time