Skip to content
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

When aggregating data tables for a week, month, year or range period, don't store all archive content in memory #18295

Closed
tsteur opened this issue Nov 11, 2021 · 12 comments · Fixed by #20332
Assignees
Labels
c: Performance For when we could improve the performance / speed of Matomo. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Milestone

Comments

@tsteur
Copy link
Member

tsteur commented Nov 11, 2021

This is a follow up from #17817 where we only expand one data table at a time.

We've noticed though we're still seeing sometimes memory issues for eg a yearly archive where it exceeds 8GB. This archive has 9 levels down of subtables and overall a lot of rows. One thing that could help with memory be in to not load the data of all data tables at once into memory.:

image

Each data table is then later expanded one at a time.

The only problem with loading the needed data tables on demand would be performance as we'd need to do a lot more select queries to get each "subchildren" data table. Maybe that means we might not want to do this or maybe we can find a compromise somehow.

refs L3-126

@tsteur tsteur added the c: Performance For when we could improve the performance / speed of Matomo. label Nov 11, 2021
@tsteur
Copy link
Member Author

tsteur commented Nov 11, 2021

I checked and in the case where we have a memory issue, $dataTableBlobs variable alone consumes 3.1GB memory. This is before any data table is expanded.

@tsteur tsteur added this to the 4.8.0 milestone Nov 11, 2021
@gijshendriksen
Copy link

I was running into memory issues in my Matomo installation, which I also discussed in this forum post. It sounds like solving this issue would also resolve my problems with the archiver. Do you also think this is the case, or do you think there is a separate issue going on there?

@tsteur
Copy link
Member Author

tsteur commented Nov 16, 2021

It might @gijshendriksen it's hard to say without knowing all the details.

Generally what might also help is to lower the number of actions in the report see https://matomo.org/faq/how-to/faq_54/

eg setting something like

[General]
datatable_archiving_maximum_rows_actions = 500
datatable_archiving_maximum_rows_subtable_actions = 100

Sometimes this does not fix it alone, and if it happens eg for a yearly period, then the archives for each month in the year would need to be invalidated see https://matomo.org/faq/how-to/faq_155/

Hae you maybe already lowered the number of rows in the reports before?

@gijshendriksen
Copy link

@tsteur thanks for your help! I wasn't aware these configuration options would help with the memory usage, but after applying your suggested changes the archiver now seems to be working again. Thanks!

@justinvelluppillai justinvelluppillai modified the milestones: 4.8.0, 4.9.0 Mar 1, 2022
@tsteur tsteur modified the milestones: 4.9.0, 4.10.0 Mar 2, 2022
@tsteur
Copy link
Member Author

tsteur commented Oct 2, 2022

We're having this issue daily quite a few times with various customers.

@tsteur
Copy link
Member Author

tsteur commented Oct 17, 2022

We again have an issue with a customer where archiving stopped working because of this issue

@tsteur
Copy link
Member Author

tsteur commented Oct 23, 2022

Seeing this issue happening again for a URL like this:

/index.php?date=2021-06-01,2022-12-31&filter_limit=300&flat=1&format=CSV&format_metrics=1&idSite=1&language=en&method=Actions.getPageUrls&module=API&period=day&segment=&token_auth=ANONYMOUS&force_session_api=1&translateColumnNames=1&convertToUnicode=0&1

Not fully sure if it is this specific problem but I assume so and it should reduce memory quite a bit if we had this logic.

image

image

@tsteur
Copy link
Member Author

tsteur commented Oct 26, 2022

Again issues today

@tsteur
Copy link
Member Author

tsteur commented Oct 30, 2022

Again happened few times.

@tsteur
Copy link
Member Author

tsteur commented Nov 3, 2022

We're having issues pretty much daily with this one

@mattab mattab modified the milestones: Impact Backlog, 4.12.4 Nov 3, 2022
@mattab mattab added the Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical. label Nov 3, 2022
@justinvelluppillai justinvelluppillai modified the milestones: 4.12.4, 4.13.1 Nov 28, 2022
@mattab mattab modified the milestones: 4.13.1, 5.1.0 Dec 5, 2022
@mattab mattab added the 5.1.0 label Jan 4, 2023
@sgiehl
Copy link
Member

sgiehl commented Apr 12, 2023

@tsteur Is this one fully fixed with #20332 ?

@tsteur
Copy link
Member Author

tsteur commented Apr 12, 2023

@sgiehl yes it is. #20512 should be merged too though.

@sgiehl sgiehl modified the milestones: 5.1.0, 4.14.x Apr 13, 2023
@sgiehl sgiehl removed the 5.1.0 label Apr 13, 2023
@sgiehl sgiehl closed this as completed Apr 13, 2023
@bx80 bx80 modified the milestones: 4.14.x, 5.0.0 Apr 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: Performance For when we could improve the performance / speed of Matomo. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
7 participants