Why is JIRA requiring high CPU from our SQL Server backend?

Question

Problem: Over the last month or so, we have noticed our SQL Server backend for Jira has been using more and more CPU on a weekly basis (as seen on the above screenshot).  This is causing slowness experienced by the end user. We have never experienced this before and we have been a customer for roughly 3 to 4 years.

I had a look into the queries being fired, one query that stood out is the the one below:

select "AO_319474_MESSAGE"."CLAIMANT", "AO_319474_MESSAGE"."CLAIMANT_TIME", "AO_319474_MESSAGE"."CLAIM_COUNT", "AO_319474_MESSAGE"."CONTENT_TYPE", "AO_319474_MESSAGE"."CREATED_TIME", "AO_319474_MESSAGE"."EXPIRY_TIME", "AO_319474_MESSAGE"."ID", "AO_319474_MESSAGE"."MSG_DATA",
"AO_319474_MESSAGE"."MSG_ID", "AO_319474_MESSAGE"."MSG_LENGTH", "AO_319474_MESSAGE"."PRIORITY", "AO_319474_MESSAGE"."QUEUE_ID", "AO_319474_MESSAGE"."VERSION" 
from "dbo"."AO_319474_MESSAGE" "AO_319474_MESSAGE" 
where "AO_319474_MESSAGE"."QUEUE_ID" = @P0 and ("AO_319474_MESSAGE"."CLAIMANT" is null or "AO_319474_MESSAGE"."CLAIMANT" is not null and ("AO_319474_MESSAGE"."CLAIMANT_TIME" is null or "AO_319474_MESSAGE"."CLAIMANT_TIME" < @P1)) 
order by "AO_319474_MESSAGE"."PRIORITY" desc, "AO_319474_MESSAGE"."CREATED_TIME" asc, "AO_319474_MESSAGE"."ID" asc offset @P2 rows fetch next @P3 rows only

Any ideas as to why the CPU usage is increasing on a weekly basis for the past month? The query above is doing clustered index scans, would it be helpful for us to add an index that would cause the above query to do index seeks instead?

Andy Heinzer · Answer

Hi Shane,

That particular AO table is used by the psmq-plugin.  This is a system plugin that is installed when Jira Service Desk is installed.   The fact that you are seeing poor database performance on this specific table leads me to believe that this is a problem with the way Service Desk is trying to manage emails.

There was a recent bug that seems related to the symptoms over in JSDSERVER-5736 : Poor performance with high CPU and a high number of SdOffThreadEventJobRunner threads.  This problem was fixed in Service Desk 4.3.0 version.  So if you happen to be running an older version, you are likely affected by this.  While upgrading Jira Service Desk is the recommended long-term solution, there is also a work-around documented on that bug ticket that should help to mitigate the performance problems here until you can upgrade.

I hope this helps.

Andy

Shane Renshaw · Answer

Hi Hasna,

Thank you for that but I believe that query is for MySQL. We use a similar script to capture queries in our SQL Server backend.

The query above is something that was captured quite a lot. Any thoughts on why that specific query may be being executed quite frequently?

Hasna · Answer

Hi @Shane Renshaw You can slow log query from JIRA DB adn find which process is taking slow log and may be work on that ? SLOW LOG QUERY : SELECT id,state,command,time,left(replace(info,' ',''),120) FROM information_schema.processlist WHERE command <> 'Sleep' AND info NOT LIKE '%PROCESSLIST%' ORDER BY time DESC LIMIT 50; Hasna