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.
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.
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'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
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.
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?
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...
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,
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG