High CPU load spikes from mysql

we’re running FreePBX 11 for several years now, but over the last few months we’re seeing growing spikes of CPU load coming from MySQLd, that recently started reaching 100%, and that I failed to get analyzed yet, so I hope for some support from here :slight_smile:

The spike occurs every 3 minutes, and takes about 1.5 minutes.
‘show full processlist’ in mysql tells me that the query is “UPDATE qxact_agent_actions, users SET qxact_agent_actions.agent = users.name WHERE (qxact_agent_actions.agent = users.extension) AND time >= $2_hours_ago”.
For some odd reason, this query ties up one core for more than a minute.
Running the same query from the mysql CLI manually comes back instantly.
The ‘qxact_agent_actions’ table when inspected comes up as completely empty, and the ‘users’ table is tiny, with our roughly 200 call center agents in there.
I have run the usual analyze/optimize/reindex table commands, but no change was noticeable, which makes me assume that the CPU load is actually coming from some spinlock or other tied up situation.
I’ve grepped through the FreePBX sources, but I couldn’t find any place where this query is actually generated… the above table name comes up only once in the installer.php.
As the load spike occurs exactly every 3 minutes, I guess it’s some kind of scheduled task… but nothing comes up in cron that would fit the bill.
Please share your insights if you have intimate knowledge of FreePBX’s database tasks :wink:

This sounds a lot like a bug. Can you create a ticket on http://issues.freepbx.org and it’ll need to get investigated. We may need a backup of your system (and that can be attached to the ticket) to see what the problem is.

Thanks for the heads-up, I’ve created a ticket as told.

Oh, I just noticed, you’re running ‘FreePBX 11’? There wasn’t such a thing. Do you mean 2.11? Or 12?

Either way, you should be upgrading to 13. If your issue is gone after you upgrade, can you please comment on your ticket and we’ll close it 8)

ok, ticket closed for FreePBX 2.11 being too old to get support for… but the hint given was good enough.
I rm-rf’ed the QXact directory from the modules, and the problem stopped instantly.
I still have no idea why the QXact queries were being run, with the module officially being disabled and never used before, but I’ll probably never find that out.