My Mautic version is: 4.2.0
My PHP version is: 7.4
My Database type and version is: MySQL 5.7 (percona)
My problem is: We’ve been running Mautic for about 4 or 5 years now, and there’s always at least 1, multi-hour, huge query running, taking at least a few hours to complete, usually between 4 to 6 hours.
Being the Systems Admin, not the Mautic user, I can’t speak much to what exactly they’re doing, if anything, to cause these, but in any case it seems like if this was normal for others, no one would be using Mautic as these queries cause pretty everything else about the system to be extremely sluggish.
When we first rolled out Mautic, we purchased a (custom?) support package, again, I’m not exactly clear on the details of that, but to my understanding we should have received support on the initial rollout, and a year afterwards – this problem has existed since the original setup. We’ve migrated to 4 different hosting environments to give the database more resources, upgraded the Mautic software to each new major version, but nothing has made any measurable impact.
I’ve tried a handful of different cron implementations to make sure they weren’t just piling on top one another, as of today, we’re trying a similar implementation to what’s mentioned on Broadcast sending stop suddenly during the process no issues from Cron Job or Queue
I don’t know how to compare the size of our setup to others, but I imagine other orgs are running much larger installs.
I won’t post the entire query, but hopefully this is useful:
SELECT ch.lead_id FROM email_stats ch WHERE (ch.date_sent >= '2022-04-25 20:13:45') AND (ch.lead_id IN ( .... snip ... thousands of numeric values ... snip ....)) AND (NOT EXISTS (SELECT null FROM lead_frequencyrules fr WHERE (fr.lead_id = ch.lead_id) AND (fr.frequency_time IS NOT NULL AND fr.frequency_number IS NOT NULL))) GROUP BY ch.lead_id HAVING count(ch.lead_id) >= '3'
db: mautic Command: Query Time: 13706 State: Sending data
db: mautic Command: Query Time: 12254 State: Sending data
Steps I have tried to fix the problem:
- Migrated to different hosting environments, each greater than the previous in terms of CPU/MEM/DISK IO
- Our devs/DBA have spent (too) many hours over the years attempting to find a solution
Please let me know if anyone needs more information, has suggestions, comments, etc.