JQL functions subtask() and parent() cause significant performance issues

In our JIRA instances where JQL search is a major piece of functionality utilized by users, we see major performance issues when certain queries are run where the functions subtask() and parent() are called.

Example query in question:
project = CVIA AND fixVersion in (versionMatches("8.4.0.*")) AND type not in (Task, Epic, Story) AND status not in (verified, released, closed) and summary ~ migrate and issue in parent("status in (verified, released, closed, deployed)")

This query has been verified to crash us every time, even when there is only a single user on the instance.

Behavior observed:
CPU will spike near 100%, then will remain at 100% until the instance crashes and needs to be cycled.

Initial investigation:
I separated out the pieces of the query and ran them individually in a non-prod instance. When running the parent() function alone, I observe a near 100% CPU spike, followed by CPU hovering around 50%. Even after the query finishes, CPU continues to hover at 50% and will not drop until the instance is cycled. 
Example queries run:
project = CVIA AND issue in parent("") 
project = CVIA AND issue in parent("status in (verified, released, closed, deployed)")

Running JQL queries with the subtask() function only yields an initial CPU spike to a max of 80% observed, then CPU falls and hovers around 20%. Query tried:
project = Clairvia and issue in subtask("resolution = unresolved " )

Since there was confusion as to whether hasSubtasks() or simply subtask() was causing the issue, we tested running hasSubtasks() alone. Results yielded an initial spike around 60%, then CPU tapers off to hover around 15% left over after completion.
Query tried: 
project = CVIA AND issue in hasSubtasks()

Running combinations of queries yielded the same results, whether the combination was hasSubtasks() and parent(), or subtask() combined with parent(). Behavior is that CPU will spike up to a max of 100% (max available on the server), then CPU falls and hovers consistently around 50% after the query completes. 
Queries tried:
project = Clairvia and issue in subtask("resolution = unresolved") and issue in parent("") 
project = Clairvia and issue in hasSubtasks("resolution = unresolved") and issue in parent("") 
project = Clairvia and issue in subtask("resolution = unresolved") and issue in parent("status in (verified, released, closed, deployed)")
project = Clairvia and issue in hasSubtasks("resolution = unresolved") and issue in parent("status in (verified, released, closed, deployed)")

All queries were run with zero users on the instance. One of the major questions I have is: Why is there a residual hang of CPU after the queries have completed?

Any help in troubleshooting this would be greatly appreciated.

Thanks,
Matt Hass

1 answer

0 vote

Matt,

What version of JIRA are you on now? There are major improvements in 6.3.4+ and you can find the details at https://jira.atlassian.com/browse/JRA-36368. Also watch https://jira.atlassian.com/browse/JRA-39375 for more improvements in future.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Posted Wednesday in Jira

Join our webinar: How 1B+ feature flag events helped us build the new Jira

Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...

111 views 0 3
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you