Memory Allocation on Jira 3.13.4 Standalone Version

David Hoffman August 10, 2012

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.

3 answers

1 accepted

0 votes
Answer accepted
Renjith Pillai
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 12, 2012

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.

http://blogs.atlassian.com/2012/08/jira-5-1-deep-dive-performance-scale/

0 votes
Sultan Maiyaki
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 10, 2012

Hi David,

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

David Hoffman August 10, 2012

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?

0 votes
Norman Abramovitz
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 10, 2012

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?

David Hoffman August 10, 2012

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.

[client]
port=3306

[mysql]
default-character-set=latin1

[mysqld]
port=3306
basedir="D:/MySQL/"
datadir="D:/MySQL/Data/"
default-character-set=latin1

default-storage-engine=INNODB
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
max_connections=800
query_cache_size=33M
table_cache=1520
tmp_table_size=16M
thread_cache_size=38
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=12M
key_buffer_size=8M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=256K

#*** INNODB Specific options ***
innodb_additional_mem_pool_size=4M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=2M
innodb_buffer_pool_size=176M
innodb_log_file_size=36M
innodb_thread_concurrency=8
innodb_file_per_table=ON
innodb_flush_method=unbuffered

Norman Abramovitz
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 11, 2012

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.

http://dev.mysql.com/tech-resources/articles/mysql_51_diagnostic_tools.html

http://dev.mysql.com/doc/refman/5.1/en/innodb-file-defragmenting.html

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.

Suggest an answer

Log in or Sign up to answer