I have a Jira 3.13.4 Standalone instance that has approximately 342K issues (in 180 projects) running as a service with a maximum memory setting of 1536MB. It is my understanding that this is the maximum allowed by the 32 bit service wrapper. At this point our installation is essentially useless because it takes anywhere from 2-3 minutes from the time you submit something for write (comment, attribute update, new ticket, etc etc).
We thought that perhaps allocating more memory to the system would increase performance, however any setting about 1536MB fails outright. We even tried starting the tomcat from the command line to see if the memory was indeed the issue. To our chagrin, we can't even go above the 1536MB cap from the command line.
Does anyone have any suggestions (other than upgrading - we are doing this in parrallel but as you can imagine there are tons of customizations that are slowing us down and therefore the likelihood of this succeeding anytime in the immediate future is slim to none)?
Note: We have already pruned about 160K issues (as well as removing obsolete projects). This had NO effect on performance, before OR after reindexing.
I am also open to the fact that I may be barking up the wrong tree... Here are the JVM statistics for my installation. It appears to me that even though it has sucked up 1479MB of RAM that it is only USING 376MB of that.
Probaly it is high time that you upgrade the JIRA to a latest version. There are lot of performance improvements and the latest one can indeed handle higher loads with the same amount of RAM/CPU available.
You are right about the fact that increasing the RAM from 1.5G is not possible due to the limitation on the maximum cap of 1.5 -2G on 32 bits JVM. I believe with the database statistics of 342K issues and over 180 Projects, the RAM allocation is too small and is possible that you will be facing a lot OOM errors and performnace issues as well.
I can say that increasing the RAM will definately have a positive impact on the performnace. Again I can say that the safest thing to do at this moment is to upgrade JIRA to the later versions which comes with the 64-bit windows installers bundeled with a 64 -bit JVM.
P.S: The memory statistics you attached is dynamic and not static. This shows the memory usage at that particualr point in time probably during startup when usage is very minimal. Check on this stats during peak usage for a clearer picture
Do you think it is sheer volume of tickets that is causing the problem? Or would having multiple instances of jira running (in separate JVMs) increase the performance? Or is there literally no way to tell?
Can you comment on the comment above regarding database contention/optimization?
Have you done any database performance tuning? I also believe the JVM tuning is not your issue since removing projects had no effect. Which database are you using? This feels more like a database fragmentation issue?
We are using mySQL Server 5.1. It is very possible that it could be a database issue. I have included my my.sql file below.
I would look at slow running queries and trace one or two operations during the off hours. I am assuming you are seeing slowness all the time. Given the type of answer you gave about the database, I have to assume you never analyzed/reorganized the database to maintain performance.
I would also try splitting your current Jira instance into thirds to get your counts down. I am assuming not all projects are related. Then import the first third into the new database and see what performance is like. Given the type of answer you gave about the database, I have to assume you never analyzed/reorganized the database to maintain performance.