We have an issue where the following query, seemingly on repeat is pushing our db requirements for Matamo through the roof;
we have disabled all plugins and this query still runs ad nauesum
Massive query should not be on repeat
At present we required a lot of extra resource to run our Matomo instance. On RDS we notice a vast query which was seemingly on repeat over and over;
The issue does not lie with plugins, we removed all non essential plugins and the query is still appearing
We are going to try and cache this query on a proxy in front of the db's
Regular setup, it happens continually on our system
Not sure what else to put, other than we don't know why this is happening!
We are trying to pinpoint it but its not plugins, maybe its on the tracker.php ?
Thanks for the quick reply @tsteur !
That looks interesting, over the last year i've noticed this;
a lot of user_ids share the same visitorid (i have no idea why), is there another way to solve this?
This might have been the issue i was having with redis a few weeks ago
Are you using Matomo 4? There by default this should not be the case unless you changed
enable_userid_overwrites_visitorid config option. If you aren't on Matomo 4, then I would recommend upgrading and this might fix the issue already.
@tsteur that screenshot was from matomo 3 (i took it about 5 months ago when i noticed) - i've actually just checked and we don't get this anymore (multi visitor_id per user_id) . We've recently upgraded to matomo 4 and that is where we found this issue we are running into with the big query.
We've added in the enable_userid_overwrites_visitorid=1 now but it doesn't seem to do much. What can we do?
we track lots of client websites and they all use set user_id. is it someway our clients have implemented the tags that could be tripping us up?
If you didn't have the problem before, then
enable_userid_overwrites_visitorid =0 would actually help you in that case likely. It might be worth a try at least temporary to see if it fixes something (might need to run it for an hour or so).
Regarding the implementation it's really hard to say without knowing details etc unfortunately.
enable_userid_overwrites_visitorid =0 seems to have done the trick, a massive thanks :)
It was either that or we also noticed the following at the bottom of the config so we removed it.
[QueuedTracking] notify_queue_threshold_single_queue = 250000
We seem to be on an even keel now!
Glad to know this helped. I'll close this for now as a duplicate of https://github.com/matomo-org/matomo/issues/16904 :)
It should definitely not have improved by