JIRA speed up

[jiyoung kim]

There are complaints about the JIRA speed.
Is there a way that you can improve the speed of JIRA

[Harry Chan]

Hi, this is the knowledge base article on JIRA performance tuning. https://confluence.atlassian.com/display/JIRAKB/JIRA+Performance+Tuning. I'd start by upgrading to JIRA 5.1 if possible due to the performance changes.

This is a link to Confluence tips https://confluence.atlassian.com/display/DOC/Performance+Tuning, but is just as useful. In particular https://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues - might be the most useful.

[Igor Sereda [ALM Works]]

Which version of Structure do you have? Although it's not clear if Structure contributes to your JIRA being slow, just in case you have an old version, I would advise to upgrade, we've added quite a few performance improvements around versions 1.4 - 1.5.

Also, if you'd like to get down to the code level, you can install our "Yourkit Profiler" plugin for JIRA, capture performance snapshot, then install YourKit trial version and analyze it - it will show you where the CPU time is being spent. You can also capture memory profile, but that will most likely kill JIRA instance for a couple of minutes, then you'll need to restart it.

Hope this helps,
Igor

[Harry Chan]

Adding a lot of memory can be good if you can afford it. This reduces the amount of garbage collection that occurs. You might like to follow the Atlassian performance tuning article and tune your newsize along with it to reduce garbage collection. However, permgen really doesn't need an increase. Permgen is only for classfiles, string constants, etc...

[Radu Dumitriu]

Oh my god! For 20K issues you had allocated 10Gb of memory ?!? 2Gb of perm size ?!?

It's not for nothing they claim memory is cheap !

Stay Clean: http://www.youtube.com/watch?v=xVFJrOlwdkw

Man drop down your mem to 256 Mb Perm size and max 2Gb on your heap.

[jiyoung kim]

now : -XX:MaxPermSize=2048m -Xms4096m -Xmx4096m

before : -XX:MaxPermSize=256m -Xms256m -Xmx10240m

DB : jTDS Type 4 JDBC Driver for MS SQL Server and Sybase 1.2.4

Issue count : 20692

I'll consider upgrade of jira to version 4.4.5.

[Harry Chan]

I'd definitely move to a newer JVM, i.e. 1.6.0_34.

How much memory do you have assigned to JIRA? That might be a problem since you've also got structure. Do you know how many issues you have? 4.4.5 should be quite a bit faster. I remember there were performance bug fixes. Can you specify the exact database you are running? The version etc?

[jiyoung kim]

java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

JIRA version is 4.4.3

and installed structure plug in.

[Sam Hall]

If you restart Jira and performance returns to normal, then I'm guessing it's an issue related to virtualisation/JVM nuances (the host is probably underpowered).

Otherwise, if performance is still bad, compare 32bit Jira performance vs. 64bit version (see comments below) or beef up resources on the server. Switching to another DB platform would almost certainly improve performance in this case too.

[Harry Chan]

We've found running JIRA on 64bit halved the re-indexing speed for us, so there must be performance gains. We tend to make a lot of admin changes and manually re-index quite often and it used to go on for up to an hour. What did you find faster in the 32bit version?

[Harry Chan]

To be honest, that simply makes it use less memory. If you're really memory constraint that answer is correct. Even though I did post that link Atlassian should upate that document. CompressedOops is enabled by default on all JVMs and the memory between 64bit and 32bit is margin at best. Maybe 25% increase and not double for sure.

64bit can be faster in a lot of cases, especially when working with files under the hood (and why re-indexing was faster for us) depending on implementation. Anyway, those are recommendations - best to experiment and see what works best for your instance.

Provided, we're not using 3gb of RAM right now either.

[Sam Hall]

I'm just going by what atlassian recommends here on the garbage collector page... https://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues#GarbageCollectorPerformanceIssues-Use32bitJREifHeap%3C2GB

[Sam Hall]

I've seen similar arguments for running 32bit JVM on 64bit archetecture on other sites, so I just put this down as another weird Java thing. Oracle have a nice summary about it here and they should know... http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_performance

So I think you're right, Atlassian need to remove that from their documentation. Seems like it's dependant on your CPU (and no doubt as you mentioned the kind of work the JVM is doing).

[Harry Chan]

Atlassian need to fix a lot of things there. Should use 1.7 where possible and the parallel collector isn't recommended for that. G1 is enabled by default. NUMA is enabled by default on supporting architectures. The JVM is quite smart now. Internally, they're still on 1.6.0_26 with escape analysis disabled. They should also increase the code cache. I've seen it being full on JIRA/Confluence lots of times on production deployments.

[Sam Hall]

Interesting, thanks.

[r]

If you run JIRA on virtualised environmnent you might like to take a look at this:

https://confluence.atlassian.com/display/JIRA/Running+JIRA+in+a+Virtualised+Environment

[Radu Dumitriu]

Which version, what jvm configuration, etc .... Have you tried to speed it up ? Where is the bottleneck? etc. You should try to determine first your problem, the one you report is too generic. Then, ask specifics if you want to be helped.

[jiyoung kim]

Hello ~ thanks for your quck answer.

cpu 2.66Ghz, Core 24 core, Mem 64, open Suse, standalone, MsSql, .. 20000Issues

[Sam Hall]

Details of your environment. OS, database, JVM, etc.