Planning Board is Slow when using Classic Boards in JIRA Agile

Still need help?

The Atlassian Community is here for you.

Ask the community

Note that this page only applies if you are using the Classic Boards (which are no longer being actively developed; read more). If you are using the new boards, please see Configuring Working Days.


The Planning Board is slow. Thread dumps show a lot entries similar to the following:

http-8083-4" daemon prio=10 tid=0x09a09c00 nid=0xe09 runnable [0x1fa81000]
   java.lang.Thread.State: RUNNABLE
	at Method)
	at net.sourceforge.jtds.jdbc.SharedSocket.readPacket(
	at com.atlassian.jira.issue.changehistory.ChangeHistory.getChangeItems(
	at com.atlassian.greenhopper.service.timetracking.DefaultWorklogHistoryService.setFirstRemainingEstimate(
	at com.atlassian.greenhopper.service.timetracking.DefaultWorklogHistoryService.computeFromDatabase(
	at com.atlassian.greenhopper.service.timetracking.DefaultWorklogHistoryService.computeTimetrackingHistory(
	at com.atlassian.greenhopper.service.DefaultStatService.getSummariesForVersionIds(


In order to accurately calculate the time tracking statistic column shown on the version panel, JIRA Agile 5.* needs to pull the change history of all issues that are under the versions shown in the Planning Board version panel. To provide better performance, JIRA Agile caches those issue work logs and change history records in memory. The JIRA administrator can configure the size of this worklog cache in JIRA via Administration -> GreenHopper -> General Configuration.

When that cache is too low, user's may experience the current symptom: after rebooting the JIRA instance, users have problems accessing the Planning Board because the cache is not utilized (yet). However, after a while the cache becomes full. Then, every time the Planning Board is displayed, JIRA Agile must visit the records in the database to pull work log and issue change history. For a light instance, this is not a concern. If the instance is big and the Planning Board is used heavily, then many change history queries triggered by the different user sessions will flood the database. (A database administrator may see a high volume of queued queries on changeitem table).


Follow these instructions. You may notice an improvement after increasing it some (i.e., 50000).

Last modified on Nov 1, 2018

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.