OutOfMemory Error or Poor Performance due to XML Backup
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Symptoms
Performance is poor, or the instance runs out of heap space memory.
For OutOfMemory Errors, logs look like:
2010-08-25 03:07:30,047 JiraQuartzScheduler_Worker-2 ERROR ServiceRunner Backup Service [jira.action.admin.DataExport] Error exporting: java.lang.OutOfMemoryError: Java heap space
For poor performance, thread dumps include threads like:
"JiraQuartzScheduler_Worker-0" prio=10 tid=0x00002aac50a61800 nid=0x21b5 runnable [0x0000000040f37000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at oracle.net.ns.Packet.receive(Unknown Source)
at oracle.net.ns.DataPacket.receive(Unknown Source)
at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
at oracle.net.ns.NetInputStream.read(Unknown Source)
at oracle.net.ns.NetInputStream.read(Unknown Source)
at oracle.net.ns.NetInputStream.read(Unknown Source)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:979)
at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:951)
at oracle.jdbc.driver.T4C8TTILob.receiveReply(T4C8TTILob.java:775)
at oracle.jdbc.driver.T4C8TTILob.getChunkSize(T4C8TTILob.java:292)
at oracle.jdbc.driver.T4CConnection.getChunkSize(T4CConnection.java:2090)
- locked <0x00002aaace9e0240> (a oracle.jdbc.driver.T4CConnection)
at oracle.sql.CLOB.getChunkSize(CLOB.java:477)
at oracle.sql.CLOB.getBufferSize(CLOB.java:493)
at oracle.sql.CLOB.getCharacterStream(CLOB.java:253)
at oracle.jdbc.driver.ClobAccessor.getString(ClobAccessor.java:241)
at oracle.jdbc.driver.T4CClobAccessor.getString(T4CClobAccessor.java:80)
at oracle.jdbc.driver.OracleResultSetImpl.getString(OracleResultSetImpl.java:355)
- locked <0x00002aaad8cb7428> (a oracle.jdbc.driver.OracleResultSetImpl)
at org.apache.tomcat.dbcp.dbcp.DelegatingResultSet.getString(DelegatingResultSet.java:175)
at org.ofbiz.core.entity.jdbc.SqlJdbcUtil.getValue(SqlJdbcUtil.java:529)
at org.ofbiz.core.entity.EntityListIterator.currentGenericValue(EntityListIterator.java:160)
at org.ofbiz.core.entity.EntityListIterator.next(EntityListIterator.java:237)
at com.atlassian.jira.action.admin.export.DefaultSaxEntitiesExporter.exportEntities(DefaultSaxEntitiesExporter.java:73)
at com.atlassian.jira.action.admin.DataExport.execute(DataExport.java:81)
at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:132)
at com.atlassian.core.action.DefaultActionDispatcher.execute(DefaultActionDispatcher.java:36)
at com.atlassian.jira.service.services.export.ExportService.invokedAction(ExportService.java:118)
at com.atlassian.jira.service.services.export.ExportService.run(ExportService.java:100)
at com.atlassian.jira.service.JiraServiceContainerImpl.run(JiraServiceContainerImpl.java:56)
at com.atlassian.jira.service.ServiceRunner.execute(ServiceRunner.java:61)
at org.quartz.core.JobRunShell.run(JobRunShell.java:191)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516)
Cause
The pertinent line in the thread above is:
com.atlassian.jira.action.admin.DataExport.execute
This signifies that the XML backup is running, and may be consuming resources. The XML backup does not scale well for large JIRA instances.
Resolution
As a temporary measure, increase JIRA's Heap Space allocation.
For a more permanent solution, use a native database tool as a backup strategy. See Backing Up Data for more information.
Was this helpful?