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
archiving job runs forever due to MultiChannelConversionAttribution #17185
Comments
@Pilot001 thanks for creating the issue. We are already working on some archiving related issues. Could be possible that the issue causing your problems might already be fixed. |
@Pilot001 could you explain what you mean by the Did you recently install or activate MultiChannelConversionAttribution? If so, can you deactivate it and see if the archive job runs? |
@diosmosis Well, it is active... but not "recently". We had it active with v3.x before and now with 4.x it is still active. |
@Pilot001 could you answer my other question and if possible provide core:archive output w/ the |
@diosmosis Oh, I'm sorry... A misunderstanding. I understood your second sentence about the MultiChannelConversionAttribution, as it was an option how it would be possible that Well, I run an strace on the php process, hoping to find a hint about what was causing that endless run. There I saw those calls "open" to files names "archive_blob_*.csv" within the matomo tmp directory. Those files exist less than a second. Pls. find the log attached up to the moment it gets stuck. |
I see, those are probably temporary batch insert files (ie, for
Ok, looking at the logs I can see the issue, and good news is that we've encountered this on cloud a little while ago and have since found a fix (the problem is in the MultiChannelConversionAttribution plugin). The fix isn't out just yet, but we should be able to release it soon. In the meantime, deactivating the plugin would solve the issue for now. When the plugin is updated and reactivated, I would recommend setting I will for now keep this issue open as a reminder. |
Great! Thank you so much for your help and advice! |
@Pilot001 actually it looks like the change was already released (in version 4.0.4). Can you upgrade your plugin to the latest version? |
OK, this version was published right after I downloaded the previous one. ;-) |
After upgrading our testing system (with very little traffic) from 3.14.1 to 4.1.1 our monitoring system alerted due to a rapid increase of the database binary logs. Investigation showed that the archive cron job (running once an hour), which usually takes a few seconds to finish, was running about 2 hours (with 2GB max_memory) and then stops because of out of memory.
Next time, the job started, it invalidated the previously created archive and started again. We already tried to invalidate it manually, but it did not help.
Running the job manually with -vvv we see a strange some strange things...
Here is the debug output of the run (just the last lines):
Meanwhile the job generates csv files in tmp directory, e. g. "archive_blob_2021_01-1e61491d2fbb205b6f8eeafd01da42d4.csv" (even here, just a few lines):
On one hand, the dates in columns 3 and 4 are out of the time period that the job should be working on (2021-01-01 to 2021-02-03). And when we continue to watch these csv files, we see that the timestamp in column 6 is always just a few seconds behind current time.
The text was updated successfully, but these errors were encountered: