Hi @jbrule, can you see what's in the archive_invalidations table? For example by running the following queries:

SELECT COUNT(*) FROM archive_invalidations;
SELECT COUNT(*), COUNT(DISTINCT name) FROM archive_invalidations GROUP BY idsite, period, date1, date2;

SELECT COUNT(*) FROM archive_invalidations;
422275

SELECT COUNT(*), COUNT(DISTINCT name) FROM archive_invalidations GROUP BY idsite, period, date1, date2;
Returns
786 rows 1,1
210712 rows 2,2
17 rows 3,3
1 row 4,3
2 rows 5,3

@jbrule ok there are far too many rows in archive_invalidations. Can you do the following:

• post the contents of the system check here
• tell me how many segments you have in your instance that are set to be preprocessed
• tell me what version you upgraded from

Can you also run the following queries:

SELECT COUNT(*) FROM archive_invalidations where status = 1;
SELECT COUNT(*) FROM archive_invalidations where name like '%VisitFrequency%';

?

post the contents of the system check here

tell me how many segments you have in your instance that are set to be preprocessed

SELECT COUNT(*) FROM piwik_segment WHERE `auto_archive` = 1 Returns "1"
tell me what version you upgraded from
3.13.6
Can you also run the following queries:

SELECT COUNT(*) FROM archive_invalidations where status = 1;
27

SELECT COUNT(*) FROM archive_invalidations where name like '%VisitFrequency%';
417795

That system check was from a couple runs back of core:archive. It runs till it exhausts RAM (about 2 hours) then I start it again.

@jbrule ok, sorry the upgrade experience wasn't so great, we should definitely fix this since it's bound to occur for other users. Since you were upgrading from 3.x, you can just:

TRUNCATE archive_invalidations;

then run the command:

./console core:invalidate-report-data --dates=<dateOfUpgrade>,today

Where <dateOfUpgrade> is the date you started the upgrade in the format 2021-07-18. Then running core:archive should work without issue.

@jbrule is this issue ongoing or has it been resolved?

It is resolved. Thank you