High CPU utilization being caused by ScriptRunner

Kyle Moseley _blueridge_cx_ February 2, 2015

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á

2 answers

2 votes
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 2, 2015

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_ February 2, 2015

Thanks. Good idea, I'll try that.

MattS
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 2, 2015

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

JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 3, 2015

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
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 2, 2015

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_ February 2, 2015

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