Documentation for JIRA 4.0. Documentation for other versions of JIRA is available too.

Skip to end of metadata
Go to start of metadata

This page provides some performance data and observations on running JIRA with VMware. The information on this page is intended to help you decide whether or not to run JIRA using a VMware product. It does not contain detailed instructions on how to set this up (please see the VMware product documentation instead).  We currently only provide information for VMware as it is the most requested platform from our customers.   At this time, we do not have plans to officially support other virtualised environments.

On this page:


Unsurprisingly, JIRA is generally slower in a virtualised environment. As can be seen in the test results below, the amount by which JIRA slows down varies based on the workload.

Under low load there are several operations which are in fact faster under VMware. This is probably due to the 4CPU VM instance running on 8 real CPUs as opposed to there being only 4 real CPUs on the baseline machine.

(info) Please note, no performance tuning was applied to VMware for these tests. It may be possible to improve JIRA performance by tuning VMWare, however this may cause other applications to run more slowly on the virtual environment. We recommend that you consult the VMware documentation before deciding whether to do this.



  • If you are a running a high-load instance, your biggest performance gain will be to run the application and database on a real machine and not on virtual infrastructure.
  • Under high-load, moving the database onto another machine will help.
  • Always ensure that there are enough virtual CPUs and memory allocated to the virtual instance. This may not be possible under VMware ESX 3.5 due to limitations of 4 vCPUs per VM.
  • Always ensure that there is enough CPU time and memory available on the physical host to service all VMs. Applications should not go into swap.
  • Use modern CPUs with VT extensions — there is still a noticeable performance penalty for using a VM with these CPUs, but it will likely be much higher when using old CPUs.
  • Carefully monitor your VMware hosts to ensure that there is no resource starvation.

VMware ESX 3.5

  • If possible, upgrade to VMware ESX 4i.
  • Under low-load, using a non-virtualised database will generally result in better response times.

VMware ESX 4i

  • Under low-load, keep the database inside the virtual machine if there is enough CPU time for both the database and application.
  • Using VMware EX 4i and virtual machine version 7, you will be able to allocate up to 8 vCPUs to an instance.

Performance Testing Setup

Server Configuration

All testing was performed on the following hardware. In the case of virtual machines, one VM per machine was configured.



Real Ram


Virtualisation Software

Virtual machine version

Virtual CPU's

Virtual Ram

Dell R610

2 x Intel 'Nehalem' Xeon E5520 (Quad Core) 1

32Gb (8x 4Gb DDR3)

2 x 15K 146Gb SAS, Raid 1 4,5

VMware ESX 3.5




Dell R610

2 x Intel 'Nehalem' Xeon E5520 (Quad Core) 1

32Gb (8x 4Gb DDR3)

2 x 15K 146Gb SAS, Raid 1 4,5

VMware ESXi 4




Dell R610

2 x Intel 'Nehalem' Xeon E5520 (Quad Core) 2,3

32Gb (8x 4Gb DDR3)

2 x 15K 146Gb SAS, Raid 1 5






  1. VT extensions were enabled in the BIOS on the machines running VMWare.
  2. VT extensions were disabled in the BIOS on the machines not running VMWare, as per Dell best practices.
  3. In order to limit the CPUs in the baseline test to match the number in VMWare, the kernel boot parameter maxcpus=4 was added to the startup.
  4. The full disk was allocated to VMware.
  5. The filesystem used in all machines was EXT3.

Installed Software

Each server was set up with identical software, as follows:

Atlassian Product

JIRA 4.0.0-Beta2


MySQL 5.0.45-7

Application Server

Tomcat 5.5.27


Java(TM) SE (build 1.6.0_07-b06), Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)

Operating System

Redhat Enterprise Linux 5.3 (Tikanga) 64bit (Kernel 2.6.18-128.2.1.el5). The file system used for all tests was EXT3 with the default options.
The following tuning was applied to the operating system, in order to allow for more memory usage by the database server and better network throughput:

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 1310720000
kernel.shmall = 4294967296
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4098 65536 16777216
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.netdev_max_backlog = 2500

Testing Tool

Performance tests were conducted with Apache Jakarta JMeter 2.3.4 using the standard JIRA performance tests.

Test Results

The following tests were performed for each application. In each case, the test was performed with a database local to the host instance (i.e. in the same operating system image) and also with the database residing on a separate, non-virtualised physical server of the same specifications as above.

Low-load JIRA

This test performs around 16 requests/second on the JIRA instance. This is not enough to saturate the host CPU time and during the test there is around 60-80% idle time.

Medium-load JIRA

This test tries to perform double the requests/second of the low load test (i.e. approximately 32 requests/second) on the JIRA instance. This is enough load to saturate the available CPU time on a 4 CPU machine.

  • No labels