@limitstudios opened this Issue on March 24th 2020 Contributor

Hi,

I'm trying to debug the cause of a MySQL gone away error caused by the "Visits over time" graph on the dashboard.

Can anyone give me some pointers on where to start file wise?

@sgiehl commented on March 24th 2020 Member

Do you have archiving triggered by browser requests or are you using a cron job to archive the reports?
When triggered by the browser it might happen, that the archiving part takes too long and the connection is interrupted in between.
It can also happen in cron archiving. This is something we already worked on for Matomo 4. See #15619

@limitstudios commented on March 24th 2020 Contributor

It's setup to use a cron job

@sgiehl commented on March 24th 2020 Member

So browser archiving is disabled in the settings?

@limitstudios commented on March 24th 2020 Contributor

yep that's correct

@sgiehl commented on March 24th 2020 Member

Are you seeing any other PHP errors in the error log? Wondering how a "MySQL gone away" can happen when working with prearchived reports only. That should actually be quite fast 🤔

@limitstudios commented on March 24th 2020 Contributor

nope PHP just has MySQL gone away in the error log, can provide you a login to verify although would need to upgrade from PHP 7.1 to PHP 7.2 for you to see the error again

@sgiehl commented on March 24th 2020 Member

So it only happens with PHP 7.2, but not 7.1. Was the error reproducible or did it only occur randomly?

@limitstudios commented on March 24th 2020 Contributor

Yep just PHP 7.2 and yep can be reproduced when viewing the dashboard each time

@tsteur commented on March 24th 2020 Member

@limitstudios I suppose you had a look at https://matomo.org/faq/troubleshooting/faq_183/ already?

Otherwise be good to try the latest release which fixes possibly server gone away in core:archive but not in climulti:request. We are seeing these in core archive as well but it's not trivial. They can happen in climulti:request should the archiving take very long. Eg you have a very long running query (for hours) etc. That be the case if you have a high traffic website. You could maybe choose to ignore them as the next archive might succeed. I know it's not ideal but be only a real problem if the data would not be archived at all (never).

I'll close this as a duplicate of https://github.com/matomo-org/matomo/issues/13717 and https://github.com/matomo-org/matomo/issues/7669

We might be looking into this issue again as we are having these issues as well but it's not a priority right now for us unfortunately.

@tsteur commented on March 24th 2020 Member

Sorry was just reading again that this happens on a regular request on Visits over time. I thought it was during archive after reading the comments.

@tsteur commented on March 24th 2020 Member

Is there a segment applied? Is segment archiving through browser disabled? If not, that could be a reason.

@limitstudios commented on March 24th 2020 Contributor

nope this is the "Visits over time" widget on the dashboard view. No segments applied and archiving through browser disabled

@limitstudios commented on March 24th 2020 Contributor

on PHP 7.2 it seems to error with MySQL gone away and shows the standard red error message saying contact site administrator

@tsteur commented on March 24th 2020 Member

Can you double check all the settings are changed as mentioned on https://matomo.org/faq/troubleshooting/faq_183/ ?

I wouldn't be able to give you any starting point otherwise. It could be some other MySQL setting that is causing it. It's weird though it only happens there. Maybe try with playing some Matomo UI settings to maybe find some pattern. Like does it work when the limit in the evolution graph is less, does it work when viewing day or week or month, ...

@limitstudios commented on March 25th 2020 Contributor

hi @tsteur yep I've done what I can on those as it's shared hosting, are there any pointers on where to look around? As soon as I roll back to PHP 7.1 it's fine. I'll try upgrading to PHP 7.3 later incase it's a edge case bug in PHP 7.2

@tsteur commented on March 25th 2020 Member

@limitstudios sorry I wouldn't know where to point to. Basically, it might just be a configuration issue. Maybe some issues could be avoided with code by catching an exception and retrying the query but you'd need to check if it's always failing with the same query. For example you'd want ideally to enable slow query log for example to see if there are some long running queries but I suppose on shared hoster you might not be able to?

Powered by GitHub Issue Mirror