IntegrityChecker may cause intensive JVM memory pressure and FullGC

Summary

IntegrityChecker (/secure/admin/IntegrityChecker.jspa) may cause intensive JVM memory pressure and FullGC. At this stage, this could be related only to com.mysql.jdbc.JDBC42ResultSet implementation.

Environment

• Jira Server and Data Center

Steps to Reproduce

1. SelectAll and run IntegrityChecker
2. Monitor GC logs

Expected Results

JIRA performs well and there is no impact for normal operations

Actual Results

Intensive memory allocation, frequent FullGC, checking GC log file will show the following:

2016-10-20T17:21:32.546+0100: 2279065.239: [Full GC (Allocation Failure)  7825M->6321M(8192M), 10.9923741 secs]

2016-10-20T17:21:54.098+0100: 2279086.791: [Full GC (Allocation Failure)  7799M->6331M(8192M), 8.0748878 secs]

2016-10-20T17:22:10.321+0100: 2279103.014: [Full GC (Allocation Failure)  7856M->6352M(8192M), 11.1664467 secs]

2016-10-20T17:22:29.799+0100: 2279122.492: [Full GC (Allocation Failure)  7826M->6510M(8192M), 11.0097723 secs]

2016-10-20T17:23:33.026+0100: 2279185.719: [Full GC (Allocation Failure)  7826M->6371M(8192M), 9.4332153 secs]

Notes

Heap dump will show large chunk of memory allocated to com.mysql.jdbc.JDBC42ResultSet :

Class Name                                  | Shallow Heap | Retained Heap | Percentage
----------------------------------------------------------------------------------------
com.mysql.jdbc.JDBC42ResultSet @ 0x6e2fe1ac8|          176 | 1,957,803,480 |     25.73%
----------------------------------------------------------------------------------------

or PieChart:

Please note com.mysql.jdbc.JDBC42ResultSet may be allocated by another JIRA (or plugin) function, this is not nessasary caused by IntegrityChecker.

Workaround

None