JIRA 4.0 : Optimising Performance
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: ProfilingTo 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 optionsVirus checkingIf 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 sharesJIRA 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 HTTPSAlthough some organisations have a requirement to run JIRA over SSL or HTTPS, please note that this this can affect performance. Database optionsJDBC driversDifferent JDBC drivers have different performance characteristics. Ensure that you are using the latest patched version of the JDBC drivers for your database. DatabasesJIRA 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 latencyThe 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 databaseJIRA 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 optionsChoose the latest JDK versionThe 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 JVMSun 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 MemoryBy 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 optionsEnable GZip CompressionJIRA 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 StandaloneIf 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 ManagementIf External User Management is turned on (not the default), JIRA will not cache users & groups, potentially resulting in slow access. Application Server optionsDatabase 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 specificationsJIRA 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 |