JIRA 7 has landed! Are you an existing JIRA user with questions about upgrading? Visit the Migration Hub for information about upgrading to new JIRA applications

Skip to end of metadata
Go to start of metadata


JIRA applications appear to be experiencing performance issues and is running slowly. This will be particularly noticeable in the following areas:

  • Reindexing
  • Searching
  • The Issue Navigator
  • Gadgets
  • Opening Issues


Disk access speed is critical for JIRA application performance, particularly due to the heavy use of disk I/O as indexes are read each time a search is made and written each time an update to an issue is committed. We have a KB article on Searching, Indexing, and filters troubleshooting which contains further information on this.

If JIRA or Confluence applications are running slowly, disk speed can be a potential root cause. It's possible to isolate that cause using this Support Tools Utility to benchmark the disk access speed.

  1. Download the Support Tools Utility.

    (warning)This is a file with a .jar extension and sometimes Internet Explorer renames these to .zip. If this is the case, rename the file to .jar; do not unzip the file.

  2. Open a terminal window (in Windows, go to Start >> Run >> type in 'cmd').
  3. When running the tool, write access to the temporary directory is required - it will create and delete a large number of files in order to calculate the disk speed.
  4. Run the Support Tools Utility with the following:

    (info) For version of JIRA 4.x and onwards, the default index directory is <jira_home>/caches/indexes. It is very important that the actual directory is used as the speed can be impacted drastically by a number of environmental conditions (further details below).

  5. Pick the average of the results to assess and review our Grading the Results section for further info on how to determine the results of the speed tests.


This basic test will perform the open, read/write, close and delete operations 1000 times to a temporary file in the java.io.tmpdir directory for each measurement, reporting the results as in the assessment section below. This test is the closest we can get to simulating the performance of a Java process when it comes to accessing the file system, allowing it to be an accurate measurement for JIRA application performance when utilizing the disk. Other disk measurement tools may provide different results if they do not measure the specific performance of the Java JDK/JRE.

The Java source can be found within the JAR - if the file is uncompressed it can be viewed.


This tool has been designed primarily to perform basic disk assessment of Java running on the operating system, not the actual speed of the disk itself. It is highly possible a very fast disk can run Java slowly due to OS-level issues. This is not a substitute for a full disk analysis software suite and if the disk appears to be experiencing hardware issues or is slow, please raise this with the System Administrator or hosting provider of the server.

When reviewing the benchmark results:

  • Focus primarily on the average result.
  • When the open & close speeds are bad and the r/w is good, the likely cause is anti-virus.
  • Open and close are important values as JIRA applications will access the indexes very often - the average search will close a file many times.
  • A high minimum and average speed may be indicative of a low speed disk or hardware fault.
  • If a disk has a high average and low minimum speed, there may be an environmental factor at play (see below for further information).

Grading the Results 

Below is a breakdown of approximate average speeds that can be used to grade the results.


Open< 40,000< 80,000> 150,000
Read/Write< 40,000< 60,000> 100,000
Close< 20,000< 40,000> 100,000
Delete< 50,000< 200,000> 300,000

Possible Causes

Examples of environmental factors that can cause slow disk access are as follows:

  • Anti-Virus software. As in our Crashes and Performance Issues Troubleshooting KB article, Anti-Virus software can be detrimental to the operation of JIRA applications as it will limit open and close times.
  • A remote disk or shared drive.
  • Synchronisation to another machine over a slow network.
  • A virtualised OS, such as VMWare (see Virtualizing JIRA (JIRA on VMware) for further information).
  • A disk defragment job may be running.
  • Hardware issues such as disk failure.
  • File system encryption.
  • Automated compression of files controlled by the OS.
  • Specific issues with the Java version and OS. This is rare occurrence, however a bug or known issue within the JVM may cause it to perform poorly on a specific OS.
  • Other applications or operations that are currently using the disk.
  • The disk capacity may be nearing full, which on some OS can slow the performance of the disk (in this particular example, it was on Solaris).

Sample Benchmarks

We have included some sample benchmarks below.


This is a premier hosting provider using disk hardware technology equivalent to a SSD.


This benchmark is of very fast disk with a virus scanner enabled.


This is a WD Black 3.0GB/s 7.2k RPM drive running 5 JIRA application instances during low load (whilst we would not ever recommend to do this, it does highlight the impact of multiple applications running on the same server).

Help us improve!

Is this article helpful?
Is it well written?
Is the content complete?


  1. What VMware product was used in this test? There are "desktop products" in which the virtualization layer runs as a process atop an underlying OS. There are "Server products" in which the virtualization layer run on bare metal. The desktop produtcs impose much more overhead than the server products.

    1. The person who wrote these tests has since left the company.

      However the results and comments above are a recommendation, if you are interested in running JIRA on a VMware or any other environment, you can run the provided utility your self and compare the results to the times above.

  2. I also got 20,000 lines of NullPointerExceptions when I ran this.  Is that normal?

    1. never mind...just need to make sure you have write access to the index directory

  3. Anonymous


    i have this result and am a little confuse 

    i have installed jira in Linux in VMware and i got this result

    ---    --    --    --    ---
    stat    avg     median  min     max
    ---    --    --    --    ---
    open    68,384  34,000  33,000  28,667,000
    r/w     32,926  27,000  23,000  2,755,000
    close   6,177   6,000   5,000   28,000
    delete  45,802  39,000  38,000  623,000
    ---    --    --    --    ---
    All times are in nanoseconds.
    ---    --    --    --    ---

    stat    avg     median  min     max

    ---    --    --    --    ---

    open    68,384  34,000  33,000  28,667,000

    r/w     32,926  27,000  23,000  2,755,000

    close   6,177   6,000   5,000   28,000

    delete  45,802  39,000  38,000  623,000

    ---    --    --    --    ---

    All times are in nanoseconds.

  4. Another Linux on VM installation:


    ----    ----    ----    ----    ----

    stat    avg    median    min    max

    ----    ----    ----    ----    ----

    open    37,694    34,000    29,000    637,000

    r/w    29,780    27,000    21,000    149,000

    close    5,613    5,000    4,000    24,000

    delete    43,141    37,000    32,000    667,000

    ----    ----    ----    ----    ----

    All times are in nanoseconds.

    Pretty impressive if you ask me...


  5. I was going to run this until I saw that write access was needed to the Jira index directory. This is little worrying.

    Can this tool be run safely on a production system?

    1. Hi David,

      Yes - it looks like it is in fact writing. If you unzip (or unjar using the java command) the jar file attached to this page, the source is included. Have a look at /com/atlassian/util/benchmark/RandomAccessFileTest.java:

          private List<TimedTestRunner> getTests()

      In there are the quick reads and writes. There's a file created, some reads and writes from it, and it gets deleted.

  6. Is there anyone who can explain the reasons for good vs. bad? I've gotten a request from a customer for further information if possible.

    1. Michael,

      I am not sure I understand the question.  Is it:

      1) Explain the reason someone might have bad disk access speeds?


      2) Explain why you would want good performance?

      The answer to #1 could be many things.  Is the drive local?  What is the configuration of the drive (single drive, RAID1, RAID2 etc.)? How fast is the bus it is running on? How fast is the drive? How big is the drive? How much I/O activity is the drive being called upon (do you have other I/O intensive applications running on the disk)?  I am sure the ideal configuration would be a super fast SSD RAID array on a super fast bus located close to the CPU - but that might be expensive.

      The answer to #2 is that JIRA indexes nearly all content from the database and stores it on the $JIRA_HOME/cache/ and if you have a big system (i.e.: 200k issues) with a lot of traffic you will need a high disk access speed to be able to provide the content to the user without delay. 

      Hope this helps...



      1. My apologies Jon. Actually, you've answered my question through #1. Thanks a bunch!


  7. It would be useful to have results from a supported platform instead of OSX. I know, I know, everyone develops JIRA on a Mac, but it is almost never the production OS.

  8. Hi,

    Save to run the checking in Production server, will it affect server performance or any issue during the run? Thanks

  9. HP


    Can anyone advise? I am getting error while run the disk checking in Linux machine:

    java -Djava.io.tmpdir=/opt/apps/jira/home/caches/indexes/ -jar support-tools.jar

    Exception in thread "main" java.lang.NoClassDefFoundError: com.atlassian.util.benchmark.RandomAccessFileTest    at gnu.java.lang.MainThread.run(libgcj.so.7rh) Caused by: java.lang.ClassNotFoundException: java.util.concurrent.Callable not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:support-tools.jar], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}    at java.net.URLClassLoader.findClass(libgcj.so.7rh)    at java.lang.ClassLoader.loadClass(libgcj.so.7rh)    at java.lang.ClassLoader.loadClass(libgcj.so.7rh)    at java.lang.VMClassLoader.defineClass(libgcj.so.7rh)    at java.lang.ClassLoader.defineClass(libgcj.so.7rh)    at java.security.SecureClassLoader.defineClass(libgcj.so.7rh)    at java.net.URLClassLoader.findClass(libgcj.so.7rh)    at java.lang.ClassLoader.loadClass(libgcj.so.7rh)    at java.lang.ClassLoader.loadClass(libgcj.so.7rh)    at gnu.java.lang.MainThread.run(libgcj.so.7rh)

    1. Hi, I just happened to see this post. I think your problem might be you're running an old version of java. You probably need 1.5 or newer. Hope this helps anyone else with the same issue.

  10. If anyone is interested i have tweaked the provided classes to allow times to be reported in csv format with timestamps.

    "Timestamp","open avg","open median","open min","open max","r/w avg","r/w median","r/w min","r/w max","close avg","close median","close min","close max","delete avg","delete median","delete min","delete max"

    This can allow trending reports to visualize behavior over time.

    1. Eddie, I'd like to have a copy of your modified class.

      1. Mike Diehn - this should work for you https://eddiewebb.atlassian.net/wiki/download/attachments/11665410/support-tools-0.0.1-SNAPSHOT-jar-with-dependencies.jar?api=v2  you must provide an extra argument of the path of the file you want to log to.

        1. Thanks, Eddie!  I'll give it a shot.

  11. I have a version of JIRA 6 installed on an Amazon EC2 Linux instance with an MYSQL database and OpenJDK 1.7.  The performance is much slower that what I observed with V5.2.7.  I am suspecting that I need some performance tuning but have been unable to find the SUpport-tools.jar referred to above on my distribution.  Could you provide me some indication on tuning that I could perform to improve the speed.  Thanks


  12. We continue to have issues with slowness since the upgrade to versions 6. We maintain around 200-250 concurrent sessions during work hours. We host 1400 projects. CPU usage is normal, but system RAM outside of the JVM (8GB), will spike and stay that way. Disk are staying in the category of "GOOD" from the above. DB is Percona latest on a separate VM and just idles along. The performance issues are continuing to escalate. We have tuned the OS and Tomcat servers, as well as the DB. Nothing is helping.

    1. Our Troubleshooting Performance Problems KB may help you out here, if it doesn't please raise a support issue with us on https://support.atlassian.com and provide the information as in providing information to support.

  13. Hi,

    We used 4.0.1 ver. Where do I copy files(suppport-tools.jar)

    I run this command on cmd = "java -Djava.io.tmpdir=<jira_home>/caches/indexes> -jar support-tools.jar"

    And return messages on cmd= "The system cannot find the file specified"

     What should I do?

  14. change <jira_home> to your actual path, e.g. "C:\Program Files\Jira\Application Data\caches\indexes" 

  15. Hi,

           Will this script recommend to run in Production instance?, Since we getting high CPU usage and affecting performance of JIRA.

    Could anyone have run into this issue?  I would like to identify which script causing this issue.