@zitrusblau opened this Issue on April 18th 2019

Hey,

just wanted to setup the archive cron but running into the following error when triggering it manually:

/path/to/matomo/core/Common.php(271): Notice - unserialize(): Error at offset 0 of 246 bytes - Matomo 3.9.1

Error: Error unserializing the following response from ?module=API&method=API.get&idSite=1&period=week&date=last260&format=php&trigger=archivephp: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>504 Gateway Timeout</title> </head><body> <h1>Gateway Timeout</h1> <p>The gateway did not receive a timely response from the upstream server or application.</p> </body></html>

Wondering what might cause this. Couldn't find a solution to this problem yet.

Raising execution times (180 sec) and memory limits (512MB) didn't help either.

ran this command with
PHP 7.2.3 (cli) (built: Mar 5 2018 11:28:44) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v10.2.5, Copyright (c) 2002-2018, by ionCube Ltd.

@fdellwing commented on April 18th 2019 Contributor

This is pretty much not a bug in Matomo, so the forums would be a better place for this.

Anyway, please take a look into your PHP error log from Matomo to see if there is anything related to the triggered archiving requests.

@zitrusblau commented on April 18th 2019

Ok, thanks. Added a new forum topic then:
https://forum.matomo.org/t/gateway-timout-issue-on-cron-archive-task/32583

Unfortunately, nothing shows up in the error logfile related to this.

@gpanagiotidis commented on May 2nd 2019

@fdellwing

How do we know that this is not a bug in Matomo?

@fdellwing commented on May 2nd 2019 Contributor

Its simple: If this would be a bug with Matomo, much more users would have it. Furthermore, a gateway timeout is a typical problem for a misconfigured PHP instance.

@gpanagiotidis commented on May 2nd 2019

504 Gateway Time-out

The server didn't respond in time.
@fdellwing commented on May 2nd 2019 Contributor

The unserialize error will always be shown if the answer from the server is not the expected, so the problem is unrelated.

What webserver are you using? Is there a reverse proxy in place? Do you use PHP-fpm (probably)?

@gpanagiotidis commented on May 2nd 2019

I am using Apache httpd deployed in Openshift. There is a reverse proxy, not configured by me. I don't know if I am using PHP-fpm, I didn't make any changes in PHP besides installing PHP and changing the two variables mentioned.

The installed packages are:

rh-php72-php \
rh-php72-php-curl \
rh-php72-php-gd \
rh-php72-php-cli \
rh-php72-php-mysqlnd \
rh-php72-php-mbstring \
rh-php72-php-xml
@fdellwing commented on May 2nd 2019 Contributor

Ok, that is a setup I cannot directly help you with. But I can say you one thing: Most webservers have a default timeout configured for proxy handling. You can override this setting, for apache see https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxytimeout.

I prefer a timeout one second shorter than your PHP max_execution_time.

For nginx with php-fpm this would look like fastcgi_read_timeout 119 if the max_execution_time ist 120 seconds.

@gpanagiotidis commented on May 2nd 2019

I am not using fpm thought. Could it be the reason I am seeing this error?

@fdellwing commented on May 2nd 2019 Contributor

Could it be the reason I am seeing this error?

Unlikely.

There is a reverse proxy, not configured by me.

All I said is valid for all proxies, php-fpm is just a very good example.

@gpanagiotidis commented on May 2nd 2019

Sometimes I am also getting:

Oops… there was a problem during the request. Maybe the server had a temporary issue, or maybe you requested a report with too much data. Please try again. If this error occurs repeatedly please contact your Matomo administrator for assistance.

In widgets (eg Visits Over Time) if I request reports for a whole year. The websites are not archived because archiving fails in many sites with the discussed error.

Maybe these issues are related but I have no idea what might be wrong in the server configuration. What do you think?

Also, I should mention that the database without any archived table is around 200GB.

This Issue was closed on April 18th 2019
Powered by GitHub Issue Mirror