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
Multiple requests may archive the same range request at the same time #18088
Comments
fyi this might be related/similar to the old report at #8444 |
@tsteur Just trying to understand this. So every single sparkline axis is loading from the archive_numeric_20xx_xx like a cache table when the enable_browser_archiving_triggering is disabled, it won't insert into archive_numeric_20xx_xx table, only |
enable_browser_archiving_triggering is disabled, but for range dates by default we still initiate browser archiving and aggregate all the different periods to a range. Meaning it will insert data into the archive tables when viewing it in the browser. Does this help? |
@tsteur kind of, so the |
yes 👍 |
This is actually not fixed yet. I added 2 new comments in DEV-2306 with details. It either doesn't help, or it helped but there are still issues. We can try another fix in Matomo 4.7 @peterhashair Maybe one potential problem with this is that all requests eventually try to get that lock vs they should maybe just wait until the lock is released if the lock is held by someone else and then not try to get the lock again. I don't think this works using the |
@tsteur ah on my local it doesn't do duplications, to reproduce this. Maybe can we dump the database from the testing server? |
@peterhashair there are pretty much no duplicates here either except for the goals flag. I'm not sure that's the problem though. I was going to export the data but it has been deleted again already by some task. I can export it again if that's helpful but not sure it would help too much. Because we have disabled |
@tsteur maybe that's not related to the lock or multiple requests, we can cache the select to the lazy cache instead of MySQL select, not sure that helps. But I can see the CPU is cluster caused by the writer, is that mean insert cause the problem not the select? |
@tsteur it seems like this is really slow when there is a large date range. matomo/plugins/Annotations/API.php Line 222 in 60a9383
|
Good find, I can see how that one might be a bit slow. Takes 2s here for me when requesting a range of 9 months. It generally does only a one simple DB query though so it wouldn't cause the big DB load. We could create another issue to improve the performance of this script eventually. |
@tsteur on my local is wired, if you run it just by itself, it takes 1-2s, but if you run it on the goal overview page. it takes 42s on my one. |
We might want to try our other lock see https://github.com/matomo-org/matomo/compare/lockalt?expand=1 The benefit here is that not every request will try to acquire the lock but only one process. And as soon as it's released this lock, the other processes won't fight to get the lock but will just know the archive is finished and continue. @peterhashair let's also try to move all these goal specific visualisations into one request Happy to show how this could be done. Generally the lock we're having is already helping, but we want to avoid extreme concurrency when people have heaps of goals. We can try to put this into one view and then see if it loads faster etc. |
@tsteur our lock looks great, but when in the larger period, eg: more than the 6-month range of period, it throws a 504 time out see screenshot. CPU usage on MySQL server is about the same 400%+, I have a feeling is the select clause of the CPU usage high, but not too sure, I trying to merge some of the select queries to see if that helps. |
@tsteur merged sparkline combine into 1 request, let me know if that still causing CPU load problems. |
great, thanks 👍 |
reopening, as the PR actually broke the goals overview and therefor was reverted. |
We noticed a while ago that multiple requests may launch archiving for the same period.
To reproduce this:
[General]enable_browser_archiving_triggering = 0 enable_general_settings_admin = 0 browser_archiving_disabled_enforce = 1
./console core:archive
2021-09-02,2021,09,29
You might then notice that all does goals trigger the archiving. Eg you could execute a query like
I'm meaning that each of these requests like in the screenshot seem to be launching the archiving (eg
index.php?forceView=1&viewDataTable=sparklines&module=Goals&action=get&idGoal=7&allow_multiple=0&only_summary=1&idSite=12&period=week&date=today&segment=&showtitle=1&random=1482
):As I'm seeing this recently more often I think this was a regression somewhere between 4.3 and 4.4. I quickly looked through the archiving related changes in 4.3.0...4.4.1 and couldn't find anything so far that would explain this. This one peaked my interest but pretty sure it cannot be what caused it: https://github.com/matomo-org/matomo/pull/17657/files
Possibly the regression was in 4.2.0 because of https://github.com/matomo-org/matomo/pull/17379/files maybe
I wonder if this one maybe previously prevented that each request launches the archiving at the same time? Once we can reproduce the issue, we could maybe see if it works with that PR and wouldn't launch multiple archives.
Let me know if there are any issues reproducing this issue.
refs #17774
The goal is that the archiving is triggered only once for all these requests. Meaning below query should return
1
:The text was updated successfully, but these errors were encountered: