New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error while sending STMT_PREPARE packet in range period processing of core:archive #7256
Comments
I started a proof of concept module allowing the cron archive process to send mysql commands before processing : https://github.com/gboddin/PiwikMysqlFixTimeout I don't know if it's related but you could use that method to fix your server settings at the connection time ;) |
Thanks for this hint, but my |
Hi @Callidior please try again with 2.12.1 as we improved performance and memory usage there. also archiving of blobs is much more efficient in 2.13.0-beta which you can download already. You may also need to increase |
Hi @mattab, |
@mattab The issue still persists in 2.13. Now, it even takes almost 2 hours to process a single website with 43 segments. After that, it fails with the same error message. |
@Callidior did you try to change your mysql server as explained in this FAQ? http://piwik.org/faq/troubleshooting/faq_183/ it should fix "mysql server has gone away" issue |
I run the
core:archive
script directly on the command line for a site with about 300 visits per day and more than 30 segments. It takes 5 to 10 minutes to process everything, but fails after year-period processing and before range-period processing with a database error:The query preceding this warning is:
I guess, that error occurs in
CronArchive::loadCustomDateRangeToPreProcess()
, but I have no idea why. The next thing I get is a fatal "MySQL server has gone away" error.This error occurs in Piwik 2.11, but also in earlier versions.
If I run
core:archive
for each period separately using--force-periods
, it works though.Here is the last part of the verbose log of
core:archive
:wait_timeout
of my MySQL server is 1 hour,max_allowed_packet
is 16 MB and I'm not allowed to change that value, but it should be sufficient for the simple query shown above.The text was updated successfully, but these errors were encountered: