Runaway memory on accessing index.php

Hi. Yes, I can’t even get the splash page to login. I have upped the memory, given it lots of swap. We have gone from a 4GB machine with 4GB of swap to an 8Gb machine with 8Gb swap.

./console diagnostics:run
INFO [10:33:49] 3423 Unable to test if mod_pagespeed is enabled: the request to failed
There are no problems with your Matomo setup. Give yourself a pat on the back.

this seems to work on the command line
php index.php
But on the browser …would run forever it seems. Has anyone seen this before.

We are up-to-date matomo 5.0.2 , we are on php8…3.
memory_limit = 16G

minimum_memory_limit = -1


Have just started seeing something similar on our install of Matomo. Been running fine for a year. Initial PHP memory limit was 128M, which we raised to 256M, and then finally 512M. It was running like that for about 6 months. Upgraded to 5.x last month. Now, today we noticed memory exhaustion messages going back to Feb 5th (sorry, no logs from further back available), and raised memory to 750M, 1G and finally 2G before it would start working. Is it possible changes to code in 5.x have contributed to this?
WRT the original poster, you shouldn’t have your PHP memory_limit greater than the amount of RAM in your machine! And as the machine is also running mysql etc, then probably the most you can try is ~ 4Gb i.e half installed RAM.


To update Mark’s post (I am a colleague): we’ve now increased to a 15GB PHP memory limit - and we’re still running out of memory.

Monolog is throwing the error, regardless of it being enabled. Matomo is in maintenance mode. We cannot even log in; Matomo runs out of memory before displaying the login page.

Issues began less than a week after upgrading to Matomo 5. Until the upgrade we ran on Matomo 4 with 128MB PHP memory for literally years, trouble-free.

Does anyone have any suggestions, please?

We have now rolled back to 4.x; we were unable to get 5.x to work, having had it initially working well for a week.

We have typically 20m page views a year over 10m visits. If anyone has success with 5.x at this level of traffic we’d like to hear from you, please.

1 Like

We have downgraded to 4.13.1 and its working. We have lost weeks of processing I guess, had to go back 2 weeks. We have updated php to 8.3 from 8.0 and its still sound. We are a big site Luke says … so it potentially a performance issue.

Fishing around for answers myself. Do you have anything in your mysql slow_query_log? I’ve got a couple of queries running for 30 and 40 seconds, which is quite a grind. Not sure if its related, but certainly odd.

# Time: 2024-02-15T03:04:42.271501Z
# User@Host: root[root] @ localhost []  Id: 210762
# Query_time: 5.148170  Lock_time: 0.000007 Rows_sent: 50507  Rows_examined: 50507
use nk_matomo;
SET timestamp=1707966277;
SELECT /*!40001 SQL_NO_CACHE */ * FROM `matomo_archive_blob_2024_01`;
# Time: 2024-02-15T03:05:42.322973Z
# User@Host: root[root] @ localhost []  Id: 210976
# Query_time: 46.360835  Lock_time: 0.000007 Rows_sent: 8715794  Rows_examined: 8715794
SET timestamp=1707966295;
SELECT /*!40001 SQL_NO_CACHE */ * FROM `matomo_log_link_visit_action`;
# Time: 2024-02-15T03:06:16.333998Z
# User@Host: root[root] @ localhost []  Id: 211076
# Query_time: 33.823712  Lock_time: 0.000002 Rows_sent: 2942961  Rows_examined: 2942961
SET timestamp=1707966342;
SELECT /*!40001 SQL_NO_CACHE */ * FROM `matomo_log_visit`;

Hi Jay, We have had to roll back so lost the logs. We are having a pause while we work out what to do. Right now it appears v5 doesn’t work for us.