JIRA speed up

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

12 answers

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.

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

Hello ~ thanks for your quck answer.

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

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.

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

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.

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?

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.

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

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.

Interesting, thanks.

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.


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?

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.

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.

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

0 vote

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

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,322 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot