High CPU utilization being caused by ScriptRunner

[Kyle Moseley _blueridge_cx_]

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.

Thanks!

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)

And

"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.

Sincerely,
Pedro Corá

[JamieA]

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.

[Kyle Moseley _blueridge_cx_]

Thanks. Good idea, I'll try that.

[MattS]

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

[JamieA]

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.

[Nic Brough -Adaptavist-]

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.

[Kyle Moseley _blueridge_cx_]

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.