@jbrule opened this Issue on July 20th 2021

I am getting the error below while the archive task is running via cron. It looks like there are a log of archive invalidations so a lot of dates are running. My PHP memory limit is set to 2048MB which is pretty high. I can see in top that over time this archive job keeps consuming more and more memory until it fails with this message.

Version: 4.3.1
PHP: 7.2.24
RHEL7

PHP Fatal error:  Allowed memory size of 2147483648 bytes exhausted (tried to allocate 65536 bytes) in /apps/apache/www/production/matomo/core/DataAccess/Model.php on line 761
ERROR [2021-07-20 14:22:03] 36417  Fatal error encountered: /apps/apache/www/production/matomo/core/DataAccess/Model.php(761): Allowed memory size of 2147483648 bytes exhausted (tried to allocate 65536 bytes)
Matomo encountered an error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 65536 bytes) (which lead to: Error: array (
  'type' => 1,
  'message' => 'Allowed memory size of 2147483648 bytes exhausted (tried to allocate 65536 bytes)',
  'file' => '/apps/apache/www/production/matomo/core/DataAccess/Model.php',
  'line' => 761,
  'backtrace' => ' on /apps/apache/www/production/matomo/core/DataAccess/Model.php(761)
',
))
@diosmosis commented on July 20th 2021 Member

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;
@jbrule commented on July 20th 2021

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

@diosmosis commented on July 20th 2021 Member

@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%';

?

@jbrule commented on July 20th 2021
post the contents of the system check here

Matomo Diagnostics

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

@jbrule commented on July 20th 2021

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.

@diosmosis commented on July 20th 2021 Member

@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.

@diosmosis commented on July 25th 2021 Member

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

@jbrule commented on July 25th 2021

It is resolved. Thank you

This Issue was closed on July 25th 2021
Powered by GitHub Issue Mirror