Matomo creates a new MySQL session on every health check

[imc67]

@Joseph isn't it strange that you set this topic to solved without checking?

@girish & @nebulon today I spend an awful lot of time to analyse this issue together with Claude.ai and this is the result:

Cloudron health checker triggers excessive MySQL disk I/O via Matomo LoginOIDC plugin

I want to report a bug that causes massive MySQL disk write I/O on servers running Matomo with the LoginOIDC plugin (which is the default Cloudron OIDC integration).

The problem

The Cloudron health checker calls the root URL / of the Matomo app every 10 seconds. When Matomo's LoginOIDC plugin is active, every single health check request causes PHP to create a new session in MySQL containing a Login.login nonce and a LoginOIDC.nonce — even though no user is logging in.

This results in exactly 360 new MySQL session rows per hour, 24 hours a day, on every server running Matomo with OIDC enabled.

Evidence

Session count per hour over a full day (consistent across 3 separate servers):

00:00 → 360 sessions
01:00 → 360 sessions
02:00 → 360 sessions
... (identical every hour, including 3am)
23:00 → 360 sessions

360 sessions/hour = exactly 1 per 10 seconds = the Cloudron health check interval.

Decoding a session row from the MySQL session table confirms the content:

a:3:{
  s:11:"Login.login"; a:1:{s:5:"nonce"; s:32:"44e6599e05b0e829ec469459a413fc11";}
  s:4:"__ZF"; a:2:{
    s:11:"Login.login"; a:1:{s:4:"ENVT"; a:1:{s:5:"nonce"; i:1772890030;}}
    s:15:"LoginOIDC.nonce"; a:1:{s:4:"ENVT"; a:1:{s:5:"nonce"; i:1772890030;}}
  }
  s:15:"LoginOIDC.nonce"; a:1:{s:5:"nonce"; s:32:"7456603093600c7a3686d560bc61acd1";}
}

These are unauthenticated OIDC handshake sessions — not real users.

Sessions have a lifetime of 1,209,600 seconds (14 days), so they accumulate without being cleaned up. On my 3 servers this resulted in 113,000–121,000 session rows per Matomo instance, causing continuous MySQL InnoDB redo log writes and buffer pool flushes of 2.5–4 MB/s disk I/O.

Today's actual visitor count in Matomo: 22 visits across 10 sites. Today's sessions created in MySQL: 4,320+.

Root cause

The Cloudron health checker calls GET / on the Matomo app. This URL triggers the LoginOIDC plugin to initialize an OIDC authentication flow and write a session to MySQL — even for a non-browser health check request with no user interaction.

Suggested fix

The Cloudron health checker should call a static or session-free endpoint instead of /, for example:

• matomo.js or piwik.js (static JavaScript file, no PHP session)
• A dedicated /health or /ping endpoint

This would eliminate the session creation entirely without requiring any changes to Matomo or its plugins.

Environment

• Cloudron v9.1.3 (9.0.17)
• Ubuntu 22.04.5 LTS
• Matomo 5.8.0 with LoginOIDC plugin
• Reproduced on 3 separate Cloudron Pro instances

[imc67]

Update on the Matomo issue https://forum.cloudron.io/post/121389

I disabled the OIDC plugin in Matomo and then the sessions are still created every 10 seconds, so it's not that plugin. Next when looking into the Matomo settings - System check it says:

Errors below may be due to a partial or failed upload of Matomo files.
--> Try to reupload all the Matomo files in BINARY mode. <--

File size mismatch: /app/code/misc/user/index.html (expected length: 172, found: 170)

The file contains:

/app/code# cat /app/code/misc/user/index.html
This directory stores the custom logo for this Piwik server. Learn more: <a href="https://matomo.org/faq/new-to-piwik/faq_129/">How do I customise the logo in Piwik?</a>

This means nothing serious.

Then I installed a Matomo app on the Cloudron demo server and was able to replicate the every 10 seconds session table increase, within 1 minute 8 extra sessions:

mysql> SELECT COUNT(*), MIN(FROM_UNIXTIME(modified)), MAX(FROM_UNIXTIME(modified)) 
    -> FROM session;
+----------+------------------------------+------------------------------+
| COUNT(*) | MIN(FROM_UNIXTIME(modified)) | MAX(FROM_UNIXTIME(modified)) |
+----------+------------------------------+------------------------------+
|       47 | 2026-03-08 10:58:00          | 2026-03-08 11:05:20          |
+----------+------------------------------+------------------------------+
1 row in set (0.00 sec)

mysql> SELECT COUNT(*), MIN(FROM_UNIXTIME(modified)), MAX(FROM_UNIXTIME(modified))  FROM session;
+----------+------------------------------+------------------------------+
| COUNT(*) | MIN(FROM_UNIXTIME(modified)) | MAX(FROM_UNIXTIME(modified)) |
+----------+------------------------------+------------------------------+
|       55 | 2026-03-08 10:58:00          | 2026-03-08 11:06:40          |
+----------+------------------------------+------------------------------+
1 row in set (0.00 sec)

[joseph]

I checked our matomo instance:

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|    20588 |
+----------+
1 row in set (0.08 sec)

Clearly, something is not cleaning up sessions.

[joseph]

I found an upstream issue regarding this - https://github.com/matomo-org/matomo/issues/22767 . But I think it's behaving as configured. https://github.com/matomo-org/matomo/blob/53e574f53f1bde8cf19df1fc7ecd8496b83b748e/config/global.ini.php#L502C1-L502C30

[General]
; By default, the auth cookie is set only for the duration of session.
; if "Remember me" is checked, the auth cookie will be valid for 14 days by default
login_cookie_expire = 1209600

I tried this now on our server. Edit config/config.ini.php

; add this under [General] section . 2 days
login_cookie_expire = 172800

Update existing sessions:

mysql> UPDATE session SET lifetime=172800;
Query OK, 20613 rows affected (0.11 sec)
Rows matched: 20614  Changed: 20613  Warnings: 0

Unfortunately, this does not clean up the sessions

[joseph]

After settings session_gc_probability = 30 in [General] (run gc 1 in 3 runs), it finally cleaned it up.

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|     2938 |
+----------+
1 row in set (0.00 sec)

[joseph]

@imc67 can you try the above settings on your server? Also, as seen above Query OK, 20613 rows affected (0.11 sec) , it took one tenth of a second to update 20000 rows. Maybe you can check how long it takes in yours. Point being that 20k rows has no effect on disk I/O on our server atleast.

[imc67]

before I started:

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|    26920 |
+----------+
1 row in set (0.01 sec)

I did your settings in #4 and #5, restarted the app

After that (with some intervals):

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|    17398 |
+----------+
1 row in set (0.01 sec)

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|    17399 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|    17395 |
+----------+
1 row in set (0.01 sec)

I see they keep "hanging" around that amount

I decided to clean it once manually to give it a clean start ..

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|        4 |
+----------+
1 row in set (0.00 sec)

[joseph]

thanks, does this help reduce i/o in a meaningful way? I guess we should continue back in the other thread.