Common causes for Jira Server crashes and performance issues
Common Causes for Performance Degradation or Crashes
Expand the titles below to see the common causes for performance issues:
When some JIRA application administrators think about large JIRA application instances, they often focus on the number of issues a single instance can hold. Yet there are so many other elements that can affect the scale of a JIRA application instance. This document explains how JIRA applications perform in different configurations and provides a guide of how to scale JIRA applications in a large enterprise: Scaling JIRA applications.
VMWare environments can cause CPU spikes and poor performance. There's an advisory - During a JIRA Evaluation or Early Implementation, CPU Spikes Due to Running on VMWare, and the tips on Run Jira server in a virtualized environment.
Search the atlassian-jira.log file for the text
java.lang.OutOfMemoryError: PermGen space. You can solve this problem by increasing your PermGen space to 256M. Make sure to specify PermGen space as opposed to heap space. PermGen space is a straight-forward increase of the memory setting.
Unlike PermGen space, Heap space memory may indicate a memory leak and can require more troubleshooting than just increasing the amount. Managing memory settings requires some analysis; there is no appropriate universal recommendation. See JIRA Crashes Due to 'OutOfMemoryError Java heap space' to eliminate memory leak possibilities from our most likely sources. Once you've done that, learn how to increase JIRA application memory.
Remote API scripts can render JIRA applications inoperable. If you've recently added a script, remove it for troubleshooting purposes or disable the Remote API.
The in-memory database HSQLDB is for evaluation purposes only. Make sure to switch databases when moving into production.
If you are experiencing slowness with JIRA applications, try running JIRA applications with virus checking configured not to scan your application installations or home directories.
JIRA applications need fast access to the local filesystem. If you are hosting JIRA applications, or their index directory, on a network share (SMB, NFS etc), this can cause a large loss in performance. Run JIRA applications with fast local disk access. See Testing Disk Access Speed.
Although some organisations have a requirement to run JIRA applications over SSL or HTTPS, please note that this this can affect performance.
Different JDBC drivers have different performance characteristics. Ensure that you are using the latest patched version of the JDBC drivers for your database.
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 from your JIRA applications, please check the ping times between the servers. See also Test database performance for Jira Server; Using the JIRA Configuration Tool; Monitoring Database Connection Usage.
In large instances, the XML backup can be inefficient. Move to the native database tools for an efficient and reliable backup solution.
We also strongly recommend not deploying multiple Atlassian applications to a single Tomcat container for a number of practical reasons. Firstly, you must shut down Tomcat to upgrade any application and secondly, if one application crashes, the other applications running in that Tomcat container will be inaccessible.
Finally, we recommend not deploying any other applications to the same Tomcat container that runs JIRA, especially if these other applications have large memory requirements or require additional libraries in Tomcat's
If you have a reverse proxy or firewall on your side, i.e. if your instance is integrated with Apache, then you would need to set the gzip compression to 'off' from JIRA -> 'Administration' -> 'Global Settings' -> 'General configuration' as that can cause performance issues.