This page last changed on Sep 09, 2009 by alui.
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).
On this page:
Summary
|
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.
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.
|
Recommendations
|
General
- 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.
Platform |
CPU |
Real Ram |
Disk |
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 |
4 |
4 |
32Gb |
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 |
7 |
4 |
32Gb |
Dell R610 |
2 x Intel 'Nehalem' Xeon E5520 (Quad Core) 2,3 |
32Gb (8x 4Gb DDR3) |
2 x 15K 146Gb SAS, Raid 1 5 |
N/A |
N/A |
N/A |
N/A |
Notes:
- VT extensions were enabled in the BIOS on the machines running VMWare.
- VT extensions were disabled in the BIOS on the machines not running VMWare, as per Dell best practices.
- 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.
- The full disk was allocated to VMware.
- 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 |
Database |
MySQL 5.0.45-7 |
Application Server |
Tomcat 5.5.27 |
Java |
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:
|
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.
|
|