High CPU utilization being caused by ScriptRunner

I'm having issues with high CPU utilization (averaging 70%+-90% of four cores) which is being attributed to Script Runner. Wondering if anyone has an idea of what exactly could be the issue? As of right now I'm investigating fields which could be trying to access objects incorrectly using the getCustomFieldValue's. Below is a response I received from Atlassian Support.


Looking at these thread dumps, from the top 4 'eating most of the cpu' list, 3 are related to the Script Runner Add-On:

"Thread-9268" daemon prio=10 tid=0x0000000019579800 nid=0x3c3 runnable [0x00002ab5205bf000]
   java.lang.Thread.State: RUNNABLE
        at java.util.HashMap.getEntry(HashMap.java:446)
        at java.util.HashMap.containsKey(HashMap.java:434)
        at com.atlassian.jira.issue.IssueImpl.getCustomFieldValue(IssueImpl.java:999)
        at com.atlassian.jira.issue.Issue$getCustomFieldValue.call(Unknown Source)
        at com.onresolve.jira.groovy.jql.LazyCustomFieldsMap.populateCache(LazyCustomFieldsMap.groovy:32)
        at com.onresolve.jira.groovy.jql.LazyCustomFieldsMap.getValues(LazyCustomFieldsMap.groovy:22)
        at com.onresolve.jira.groovy.jql.LazyCustomFieldsMap.get(LazyCustomFieldsMap.groovy:59)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1508)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3300)
        at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:161)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.getAt(DefaultGroovyMethods.java:209)
        at org.codehaus.groovy.runtime.dgm$293.invoke(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:271)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:53)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
        at Script4.run(Script4.groovy:1)
        at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:315)
        at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:111)
        at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233)


"http-bio-8443-exec-4632" daemon prio=10 tid=0x00002ab570118000 nid=0x603c runnable [0x00002ab5211c3000]
   java.lang.Thread.State: RUNNABLE
        at java.util.HashMap. (HashMap.java:278)
        at java.util.HashMap. (HashMap.java:318)
        at org.ofbiz.core.entity.GenericEntity. (GenericEntity.java:160)
        at org.ofbiz.core.entity.GenericValue. (GenericValue.java:89)
        at com.atlassian.jira.issue.fields.CustomFieldImpl. (CustomFieldImpl.java:250)
        at com.atlassian.jira.issue.fields.CustomFieldImpl. (CustomFieldImpl.java:239)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getCustomFieldsFromIds(DefaultCustomFieldManager.java:460)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getCustomFieldObjects(DefaultCustomFieldManager.java:445)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getCustomFieldObjects(DefaultCustomFieldManager.java:368)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getCustomFieldObjects(DefaultCustomFieldManager.java:356)
        at com.atlassian.jira.issue.managers.DefaultCustomFieldManager.getCustomFieldObjects(DefaultCustomFieldManager.java:343)
        at com.atlassian.jira.issue.CustomFieldManager$getCustomFieldObjects$0.call(Unknown Source)
        at com.onresolve.jira.groovy.GroovyCustomField$_getValueFromIssue_closure1.doCall(GroovyCustomField.groovy:126)
        at sun.reflect.GeneratedMethodAccessor2073.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)


I'd recommend you to temporarily disable the add-on if possible, or review the scripts as they are not working properly.

Let me know your thoughts.

Pedro Corá

2 answers

At least one of those is your script field code, from the stack trace and if you are using an inline script, you cannot tell which one it is. I would consider moving that code to a file, then from the thread dump you can see which of your fields is misbehaving.

It's probably worth doing a quick audit of your script fields... how many do you have, what do they do etc.

Thanks. Good idea, I'll try that.

You may be able to reimplement the scripted fields as a plugin but they may be going too much overall

Hrm... if you do a direct translation of your code to java you will have the same problem, IF the issue is in your code and not Script Runner as I suspect. If you fix it in java, you could apply the same fix to your script and the problem will go away.

1 vote

It's not directly the script runner causing the problem, it's going to be the scripts being run by it.

It's almost impossible to tell what the scripts are doing from the fragments of log report you've given, we need to see the scripts themselves really.  The best I can do from them is tell you one of the scripts looks like it is looking at custom field value data, possibly over a wide range of issues, which might chew up a lot of time or memory, but it's hard to say more.

Sure. I guess the worst case scenario is that it's not some error / logical problem caused by my scripts, but rather occurring through use. I'm currently working to make this project / its workflow less reliant on Script Runner in hopes to improve the performance. Thanks for the answer.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,171 views 5 10
Read article

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