[#JRA-8449] Integrity Checker memory usage is not constant

JIRA

Integrity Checker memory usage is not constant

Created: 08/Nov/05 10:36 AM Updated: 30/Jul/06 07:37 PM

Component/s:

Administration, Backend / Domain Model, Performance

Affects Version/s:

3.3.2

Fix Version/s:

3.4.3

Time Tracking:

Not Specified

Environment:

« Hide

System Date mardi, 08 nov. 2005
System Time 17:16:51
Java Version 1.4.2_09
Java Vendor Sun Microsystems Inc.
JVM Version 1.0
JVM Vendor Sun Microsystems Inc.
JVM Implementation Version 1.4.2_09-b05
Java Runtime Java(TM) 2 Runtime Environment, Standard Edition
Java VM Java HotSpot(TM) Client VM
User Name adminweb
User Timezone Europe/Paris
User Locale français (France)
System Encoding Cp1252
Operating System Windows 2000 5.0
OS Architecture x86
Application Server Container Apache Tomcat/5.0.19
Database type oracle
Database JNDI address java:comp/env/jdbc/JiraDS

Issue Links:

Blocker

This issue is blocked by:

~~JRA-6087~~ Don't connect tomcat with mysql

Reference

This issue relates to:

~~JRA-8448~~ Excel Export memory usage is not constant

Participants:	Akshaya Kumar Naik, Nick Menere [Atlassian] and Richard THIBAULT
Since last comment:	2 years, 42 weeks, 4 days ago
Resolution Date:	22/Dec/05 06:14 PM
Labels:

Description

« Hide

When we start the integrity checker on our large database (there are more than 14000 issues), JIRA throws a java.lang.OutOfMemory.
It means that the memory usage of the integrity checker is not constant and depends on the volume of the database.

It's a big problem because we need to solve a functional integrity in a workflow.

Could you solve this problem quickly ?

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Akshaya Kumar Naik added a comment - 17/Nov/05 02:08 PM

We have the same problem too with 13000 issues.

[ Permlink | « Hide ]

Nick Menere [Atlassian] added a comment - 19/Dec/05 05:16 PM

As of 3.4.3 this should be ALOT more memory efficient a faster.

Running against our Jira data:

Database Statistics
Issues	16173
Projects	25
Custom Fields	13
Workflows	2
Users	13597
Groups	13

Running against DB2 and Oracle on a seperate machine it took under 3 minutes and never went above 127MB of RAM.

This is in 3.4.3 and 3.5 onwards.