Running into resource limitations - unable to use 1-click upgrade.

[Whispar1]

So lately, I have been having a fair amount of 404's, 503's and a few 500 errors. I say fair because for the past year - I rarely get any of them. This was mostly happening in the BO when loading a module page or accessing stats page - very random and I can deal with it. But lately (past 2 weeks) it's happening in the FO and that is not good for potential visitors. My host is telling me I am running up against resource limits. (which I do not quite get because nothing has changed other than trying to do a 1-click upgrade that never materialized because I got a 503 at the first apache call!) 

 

What is the best way to go about figuring out why I am running up against resource limits because for the life of me, I have no clue what would have changed all of a sudden.

 

Thanks for any input. 

Edited June 16, 2014 by Whispar1 (see edit history)

[Whispar1]

Bump

[Whispar1]

I'll try one more time... 

I try and help a lot of people here (within my scope of knowledge)...

I could really use a little guidance from someone more knowledgeable than I because this is killing my store

and ability to move forward. I am willing to switch hosts, fresh install, etc.... just need a bit of insight please.

Host says I/O limits (which is set at 1024) are being hit as soon as I click 1-click upgrade. Apache timeouts are set at 30seconds. So is this a host issue or a PS issue?

Edited June 16, 2014 by Whispar1 (see edit history)

[El Patron]

can you ask you hosting provider to set the max execution time to 300 seconds until after uprage or you can also try doing this yourself by modifiying the prestashop file config/config.inc.php

 

ini_set('max_execution_time', 300);

 

add this near the existing ini__sets you see there.

 

note: you can also if possible change your existing php.ini

 

to know if your changes are in affect, use this free module:

http://www.prestashop.com/forums/topic/278164-free-module-display-php-environment-phpinfo-back-office/
 

 

are you doing this on our production shop or a test shop? (always best to do a test shop first)

 

and  back up back up back up

[Whispar1]

Thank you El Patron for taking the time - I appreciate it.

 

Here are my current php.ini settings (thanks for the module tip - it also confirms these settings):

max_execution_time = 10000     ; Maximum execution time of each script, in seconds
max_input_time = -1	; Maximum amount of time each script may spend parsing request data
memory_limit = 1024M      ; Maximum amount of memory a script may consume (32MB)
suhosin.get.max_vars = 10000;
suhosin.post.max_vars = 10000;
max_input_vars = 10000;

I am doing this on my production site. It has been up and running since early last year with 1.5.3.1

However, there are bugs in the install that now affect things I need to be able to do (i.e. csv import/export, available date settings with combinations, etc.) I do understand what you are saying with a test shop but I am left with no other options  I'm not trying to go to 1.6 unless necessary, merely 1.5.6.2 in hopes that these issues get fixed.

 

And yes - I always back up - you drilled that into my head when I first started with PS over a year ago

Edited June 16, 2014 by Whispar1 (see edit history)

[Whispar1]

I did go ahead and make the change in config.inc.php as suggested (since the php.ini already seems to be acceptable?)

No change - I/O still pegging out when starting 1-click upgrade.

[El Patron]

dang, wish I was more help.  can you check the error log from hosting side, i/o limit when I search, is just this post.

[Whispar1]

It's okay - you tried.

Believe it or not, aside from the 503's which are timeout related (due to the I/O issues) there are no error logs.

I checked them in my cPanel and nothing. I have asked the host to check on their end too but it appears as if it is simply the

1-click upgrade that is causing this because I have never had this issue with any other function in my shop (aside from sql queries from MS access timing out but that is a whole other story!) I'll post what the host finds (if anything) but it appears as if maybe I am stuck with 1.5.3.1 - so much for scalability

[Whispar1]

Okay - after reviewing complete error logs, the only thing I can find associated with 1-click upgrade is this:

 

referer: xxxxxxxxxxxxxxxxxxxx ?controller=AdminSelfUpgrade&token=5a599e5..................

 

Cannot load the ionCube PHP Loader - it was built with configuration API220090626,NTS, whereas running engine is API220100525,NTS,

Zend Guard Loader requires Zend Engine API version 220090626.

The Zend Engine API version 220100525 which is installed, is newer.

Contact Zend Technologies at http://www.zend.com/ for a later version of Zend Guard Loader.

 

(core:error) Script timed out before returning headers: ajax-upgradetab.php

 

 

1-click upgrade Ver. 1.3.11

PHP Ver. 5.4.29

 

Is this a PS native module issue? Server Issue? Any thoughts on this?

Edited June 17, 2014 by Whispar1 (see edit history)

[El Patron]

possible you find useful info in this search

https://www.google.com/search?q=Cannot+load+the+ionCube+PHP+Loader+site:forum.ioncube.com&client=firefox-a&hs=Pzh&rls=org.mozilla:en-US:official&channel=sb&gws_rd=ssl

[Arnel]

Hello Whispar,

 

As per our emails, I went through the link you provided (the topic and posts above) and here are my 2 cents on the issue.  Our host (InMotion Hosting) also uses the Zend Engine version 220100525 which is the most current release.  I would suggest trying to rename the PHP.INI file in your PrestaShop installation and see if the default server one will meet your needs.  We  have been seeing this pop-up with many WordPress installations.  I've typically removed the php.ini file and then site works with no problem.  And it's all related to the Zend Engine.    However, in your case, it does appear to be more resource related.  I think that what the others have provided above has been good advice in terms of resources used.  The only way that you're going to be resolving this is in working with your current host's technical support, if they're willing to help identify the cause - if there's anything more than what you have already provided.  From a hosting point of view, I would have to test it here to determine if our shared hosting would be a good solution versus using a VPS.  

 

Apologies for the headaches with the 1-click-upgrade.  Let us know if you find a solution.  

[Whispar1]

Thanks guys.

I am wondering if the failure to load the ioncube loader is constantly looping and therfore reaching the I/O limit. The above errors repeat a dozen times or so until it throws the last error (script timeout)

Is that how this works?

Edited June 17, 2014 by Whispar1 (see edit history)

[Whispar1]

Okay - here is the official response from my host (and they have been very good in the past so I don't know that I doubt them at this point)

 

Those errors about ioncube and zend aren't causing the problems. The "script timed out before returning headers" error is the only issue out of the snippet of log you included.

There is just simply too much data when it goes to upgrade, it takes a long time. We have our shared hosting environment set with very tight timeout values to provide the best performance possible to the many clients on each server. As mentioned previously, the best course of action would be to perform a more manual upgrade of your site software.

If you just want it to work with the one click upgrade, your options are:

A. Size down your site

B. Upgrade to a hosting package like a dedicated server before trying the upgrade

 

So, because I do have pretty decent specs on the shared platform (certainly comparable to other hosts, including PS preferred hosts) Does this mean that a 1-click upgrade simply can not be done unless on a VPS? If this is really the case, why offer shared hosting "tuned for PrestaShop" that can not perform this function? I just want to get to the bottom of this to find out where the real problem lies and hopefully help others with a solution because a search for this problem yields a lot of unanswered posts.

Edited June 18, 2014 by Whispar1 (see edit history)

[NemoPS]

That is really weird, indeed, I wonder how "tight" these limitations are. Well at this point you can download the whole site, upgrade locally and re-upload everything

[benjamin utterback]

Your web host should be able to increase the timeout settings temporarily, if only to upgrade your website.

What settings in the php.ini file can you change?

[Arnel]

Hi Benjamin,

 

Whispar said he changed the following earlier:

 

max_execution_time = 10000 ; Maximum execution time of each script, in seconds
max_input_time = -1    ; Maximum amount of time each script may spend parsing request data
memory_limit = 1024M ; Maximum amount of memory a script may consume (32MB)
suhosin.get.max_vars = 10000;
suhosin.post.max_vars = 10000;
max_input_vars = 10000;

 

 

However, it appears that either the changes are not applying, or they're not having enough of an effect to make a difference for the upgrade.  

 

I can say that from our point of view (at InMotion), the customer has access to a local PHP.INI file that they can set the website to use as opposed to the server-wide default file that the user cannot modify or access.  I was asking around my office about this issue and it's difficult to say, because it is possible that the site is very large and resources on a shared server could be the limiting factor.  The suggestion I was given was to temporarily raise the memory limit very high in the local php.ini file and then bring it down again when the upgrade is complete.  Also, try to run the upgrade during off-peak hours to be able to get more resources from your shared server.  

 

If he were to host with us, it's possible to upgrade to a VPS and then downgrade - though downgrades require a review by the systems team.  I do understand that the economy of a shared host is good for a shop, but if the shop is beginning to require resources beyond what a shared hosting server can provide, then they may need to consider upgrading.  

 

Whispar- you're welcome to try setting up an account with us to try the upgrade, but that would be up to you.  Let us know if you have any further questions.

[El Patron]

Okay - after reviewing complete error logs, the only thing I can find associated with 1-click upgrade is this:

 

referer: xxxxxxxxxxxxxxxxxxxx ?controller=AdminSelfUpgrade&token=5a599e5..................

 

Cannot load the ionCube PHP Loader - it was built with configuration API220090626,NTS, whereas running engine is API220100525,NTS,

Zend Guard Loader requires Zend Engine API version 220090626.

The Zend Engine API version 220100525 which is installed, is newer.

Contact Zend Technologies at http://www.zend.com/ for a later version of Zend Guard Loader.

 

(core:error) Script timed out before returning headers: ajax-upgradetab.php

 

 

1-click upgrade Ver. 1.3.11

PHP Ver. 5.4.29

 

Is this a PS native module issue? Server Issue? Any thoughts on this?

 

this is the same

error :

Cannot load the ionCube PHP Loader - it was built with configuration API220090626,NTS, whereas running engine is API220100525,NTS,

Zend Guard Loader requires Zend Engine API version 220090626.

The Zend Engine API version 220100525 which is installed, is newer.

Contact Zend Technologies at http://www.zend.com/ for a later version of Zend Guard Loader.

 

http://forums.cpanel.net/f5/cannot-load-ioncube-php-loader-built-configuration-api220-319821.html

 

I'm not saying this is your upgrade issue,  but something that you can  bring to your hosting support.

[Whispar1]

Hi Benjamin,

 

Whispar said he changed the following earlier: I agree with your comment on "plan switching" because that has been mentioned several times as a solution. 

 

max_execution_time = 10000 ; Maximum execution time of each script, in seconds

max_input_time = -1    ; Maximum amount of time each script may spend parsing request data

memory_limit = 1024M ; Maximum amount of memory a script may consume (32MB)

suhosin.get.max_vars = 10000;

suhosin.post.max_vars = 10000;

max_input_vars = 10000;

 

 

However, it appears that either the changes are not applying, or they're not having enough of an effect to make a difference for the upgrade.  

 

I can say that from our point of view (at InMotion), the customer has access to a local PHP.INI file that they can set the website to use as opposed to the server-wide default file that the user cannot modify or access.  I was asking around my office about this issue and it's difficult to say, because it is possible that the site is very large and resources on a shared server could be the limiting factor.  The suggestion I was given was to temporarily raise the memory limit very high in the local php.ini file and then bring it down again when the upgrade is complete.  Also, try to run the upgrade during off-peak hours to be able to get more resources from your shared server.  

 

 

Benjamin,

Arnel posted above what my settings are

 

Thanks for the input Arnel - The changes are applying - confirmed by El Patrons module.

 

I am curious... not being confrontational at all , what would you consider a very large site? I have approx 800 products and a DB size of approx 39 mb ... Aside from this 1-click upgrade issue - I have not had any issues.

[benjamin utterback]

Oops, I didn't cat

 

Benjamin,

Arnel posted above what my settings are

 

Thanks for the input Arnel - The changes are applying - confirmed by El Patrons module.

 

I am curious... not being confrontational at all , what would you consider a very large site? I have approx 800 products and a DB size of approx 39 mb ... Aside from this 1-click upgrade issue - I have not had any issues.

Oops sorry about that. 

 

Okay, well look, Shared Server settings have so many variables. I have seen many small hosts lift a memory limit temporarily to allow a user to upgrade or run a heavier script. 

 

That said, all serious store's should be run on a VPS at least. Shared servers are fine in many cases, but speed is king and I wonder if switching to a VPS will end up making you more money in the near future.

[Arnel]

Hello Whispar,

 

I don't mind the "what is a large site question?".   It definitely varies from place to place.   A 39 MB database and 800 products doesn't appear to be a large site to me.  However, we rate a site on a shared server based on total resource consumption when its running.  This includes CPU time, memory usage, and the traffic that your site incurs.  I think that the upgrade process is exceeding the boundaries of the shared server, but again, we can't really determine if our own shared servers would react the same way because we can't determine the actual resource consumption based on what we have seen.  

I hope that helps to answer the question.  Let me know if you have any further questions or comments.

[khodari]

Hi:

 

I have a similar? problem. I cannot upgrade from 1.5.3 to 1.6.8 using 1-click upgrade. I run into 500 server error. On turning on debugging the problem is defined as

 

Fatal error: Call to undefined method AdminSelfUpgrade::addJQuery() in /homepages/1/d92569321/htdocs/wsb3571297901/shop/modules/authorizeaim/authorizeaim.php on line 132

 

Can any one help with that please?

 

Thanks in advance.

 

Nabil

[khodari]

I got the answer. I uninstalled authorize.net module. Then I ran into a problem with the giveit module, which I also uninstalled. No 1-click upgrade works.

 

Sorry for being temporary stupid (hope it is not permanent)

[khodari]

Hmmm. I am in deep trouble. After trying to upgrade using 1-click, I got this error Ajax / Server Error for action upgradeFiles] textStatus: "error " errorThrown:" " jqXHR: " "

 

Now, I cannot even log to the site "server error 500". I am going to restore the site, but I still need to upgrade.

 

Still need help.

 

Nabil

[NemoPS]

only 500? nothing with debug turned on?

[Whispar1]

The 500 error is probably due to a time out from your host or you have exceeded i/o limits. I'd be willing to bet if you are in chrome and you hit f12, you will see this. I would also recommend going to 1.5.6.2 FIRST, get it stable and THEN go to 1.6xxx

 

Here is what I was able to do (this may not work for you as hosting environments are different) Fortunately for me, there is a level 2 tech that treats customers like customers instead of a number (Thank you Kyler) and he was able to tweak some things server side that allowed the update to go through effortlessly:

 

php.ini settings:

1) lowering the memory_limit to 512MB 

2) raising the max_execution_time to 20000

3) adjusting the max_input_time from -1 to 20000

 

server-side

1) resolved a minor PHP warning message

2) choosing not to run any additional backups during the upgrade

3) changed the ModSecurity read time for

 

You need to contact your host and see if they will work with you on this. If they are not willing (or able to do so) The only option you will have is a manual update and trust me, you want to do this on a dev site first (not your live store) AND you might want to consider hiring someone experienced to help out. DH42 would be an excellent option as he knows Prestashop and servers inside and out and can save you a lot of headaches.

 

Best of luck