This page last changed on Jun 01, 2009 by alui.

While implementing some of the following steps to help improve the performance of your JIRA install, it will also help to gather some data on just where your performance bottlenecks might be. See Is your JIRA Running Slowly for a step-by-step guide on gathering the type of information you will need to help diagnose and resolve performance problems.

On this page:

Profiling

To quantify performance problems, you can turn JIRA profiling on. You will then get a profile for each URL requested in the logs:

[Filter: profiling] Turning filter on [jira_profile=on]
[116ms] - /secure/Dashboard.jspa
  [5ms] - IssueManager.execute()
    [5ms] - IssueManager.execute()
      [5ms] - Searching Issues
  [29ms] - IssueManager.execute()
    [29ms] - IssueManager.execute()
      [29ms] - Searching Issues
        [28ms] - Lucene Query
          [23ms] - Lucene Search

One performance problem with JIRA can be the application server that you are running. The database connection pooling, JSP compilation times and resource allocation are different between application servers. Known slow servers include JBoss 3.x, Tomcat 4.0 and Tomcat 4.1.24. The fastest servers for JIRA at the moment are more recent versions of Tomcat, as well as Resin and Orion.

Databases can also have a large impact on performance, particularly if the database is accessed across a network, or has not been indexed properly.

If you can't change your application server, there are performance improvements available, both by tuning your server, database and through setting certain JIRA options.

Environment options

Virus checking

If you are experiencing slowness with JIRA, try running JIRA with virus checking disabled. As JIRA creates many temporary files, virus checking software can slow JIRA dramatically. McAfee's NetShield 4.5 in particular claims to let you exclude folders from scanning, but doesn't actually - upgrade to 7.0.0 to fix this. Symantec must be uninstalled - painful experience has proven that even stopping the services does not prevent it slowing JIRA down.

Network shares

JIRA needs fast access to the local filesystem. If you are hosting JIRA, or its index directory, on a network share (SMB, NFS etc), this can cause a large loss in performance. Run JIRA with fast local disk access.

SSL or HTTPS

Although some organisations have a requirement to run JIRA over SSL or HTTPS, please note that this this can affect performance.

Database options

JDBC drivers

Different JDBC drivers have different performance characteristics. Ensure that you are using the latest patched version of the JDBC drivers for your database.

Databases

JIRA Standalone (and many application servers) ship with an in-memory database like hsqldb. Using another database (e.g. MySQL, PostgreSQL or Oracle) will usually result in higher performance.

Network latency

The latency between the database server and the server hosting JIRA can be a source of performance problems. If the database is hosted on a different machine to JIRA, please check the ping times between the servers.

Index your database

JIRA 3.0+ automatically creates database indexes when the database is first created. However, if you have been doing in-place JIRA upgrades from earlier versions (not dropping/recreating the database tables), your database will not be indexed. Doing a full XML backup and restoring into an empty database will fix this. Additional indexes may be created by hand, but this is usually not necessary.

JDK options

Choose the latest JDK version

The latest JDKs contain performance optimisations that will improve the performance of JIRA. JIRA uses a lot of reflection, which was greatly improved in the 1.4 release.

Use the Server JVM

Sun ships two versions of the JDK, a client version and a server version. They have different characteristics such as memory management and inline optimisations. You may need to explicitly start your application server like "java -server -jar <app-server-jar>.jar". With JDK 1.5 it is best to leave this unset.

Allocate enough Memory

By default, many application servers are not started with enough memory for JIRA to run at an optimum speed. A lack of memory increases garbage collection time, as garbage collection has to be run more frequently.

To see if lack of memory is causing slowness, please add these parameters to JIRA's startup command:

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc -Xloggc:${LOG}/gc.log

Where ${LOG}/ is a filesystem path to your log directory. Garbage collection times will then be logged in gc.log.

You may need to start your application server like "java -server -Xms100m -Xmx300m <app-server-jar>.jar". See Increasing JIRA Memory for more details.

JIRA options

Enable GZip Compression

JIRA can compress page contents between the server and your browser, resulting in improved performance especially over slow connections. Check that GZip compression is enabled in Administration -> Global Settings -> General Configuration (unless you are using mod_proxy .

Remove HSQLDB parameters in JIRA Standalone

If you are using JIRA Standalone modified to use an external database, make sure you delete the highlighted section in your conf/server.xml, which otherwise results in poor performance:

      <Resource name="jdbc/JiraDS" auth="Container" type="javax.sql.DataSource"
        username="jirauser"
        password="jirapassword"
        driverClassName="com.mysql.jdbc.Driver"
        url="jdbc:mysql://localhost/jiradb?autoReconnect=true"
        minEvictableIdleTimeMillis="4000"
        timeBetweenEvictionRunsMillis="5000"
        />
        

External User Management

If External User Management is turned on (not the default), JIRA will not cache users & groups, potentially resulting in slow access.

Application Server options

Database Connection pooling.

Obtaining a connection to a database is an expensive operation, and most application servers maintain a pool of open connections to reduce this overhead. It is worth checking that you have a sensible number of connections pooled, sensible expiry times etc. This is configured in your app server.

If you are using the standalone version of JIRA or Apache Tomcat you can modify the DBCP connection pool in Tomcat's server.xml (or possibly jira.xml, depending on how you have setup JIRA). The values you will be most interested in modifying are the following:

                <Resource name="jdbc/JiraDS" auth="Container" type="javax.sql.DataSource"
                username="sa"
                password=""
                driverClassName="org.hsqldb.jdbcDriver"
                url="jdbc:hsqldb:${catalina.home}/database/jiradb"
                minEvictableIdleTimeMillis="4000"
                timeBetweenEvictionRunsMillis="5000"
                maxActive="20"
                    minIdle="4"
                    maxIdle="8"
                />
            

For information on what these values mean please view the Apache DBCP documentation

Other application server tuning may be of benefit. Consult your application server documentation for more information.

Server specifications

JIRA performance is very dependent on CPU and available memory. Lack of physical memory, or overly high maximum heap size setting (the -Xmx flag) can seriously degrade JIRA performance, as memory accesses result in constant swapping of data between memory and disk (virtual memory).

On Windows, you can see what your system is doing in the Task Manager:

On Linux/Solaris, vmstat 1 will print virtual memory and CPU statistics:

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 9  0 520512  27132  15216 318944    3    2    65    40    0     3 10  3 85  2
12  0 520512  27004  15216 319080    0    0   104     0 2041 10992 88  8  3  0
20  0 520512  26764  15228 319068    0    0     0   436 2196 12869 85 13  2  0
11  0 520512  26700  15228 319068    0    0     0     0 1959  4041 88  9  4  0
20  0 520512  25724  15228 319068    0    0     0     4 2137  3307 84 14  2  0
17  0 520512  25724  15228 319068    0    0     4     0 2017 10488 89  8  3  0
 9  0 520512  25468  15228 319068    0    0     0     0 1886  7532 86 11  3  0
...

(this is a very busy server with ~97% CPU usage, but fortunately no swapping)

This system info can be captured over a long time with vmstat -n 1 > vmstat.log

On Linux, CPU and memory info can be obtained with cat /proc/cpuinfo and cat /proc/meminfo respectively.

If you need to raise a support request, please include this info (vmstat 1, /proc/cpuinfo, /proc/meminfo).


Document generated by Confluence on Oct 06, 2009 00:26