症状

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 java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:129)
	at java.io.DataInputStream.readFully(DataInputStream.java:178)
	at java.io.DataInputStream.readFully(DataInputStream.java:152)
	at net.sourceforge.jtds.jdbc.SharedSocket.readPacket(SharedSocket.java:841)
...
	at com.atlassian.jira.issue.changehistory.ChangeHistory.getChangeItems(ChangeHistory.java:86)
	at com.atlassian.greenhopper.service.timetracking.DefaultWorklogHistoryService.setFirstRemainingEstimate(DefaultWorklogHistoryService.java:351)
	at com.atlassian.greenhopper.service.timetracking.DefaultWorklogHistoryService.computeFromDatabase(DefaultWorklogHistoryService.java:110)
	at com.atlassian.greenhopper.service.timetracking.DefaultWorklogHistoryService.computeTimetrackingHistory(DefaultWorklogHistoryService.java:69)
	at com.atlassian.greenhopper.service.DefaultStatService.getSummariesForVersionIds(DefaultStatService.java:101)

原因

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