You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
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.
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 :
WHERE command <> 'Sleep'
AND info NOT LIKE '%PROCESSLIST%'
ORDER BY time DESC LIMIT 50;
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?