We have an instance of JIRA that we plan to migrate into vSphere (or at least we'd like to).
However, we're having problems trying to understand the setup that Jira would need.
I run about 9 VMs per host at the moment, all single vCPU, Running exchange, SQL, Domain Controllers etc. Overall Host CPU sits at about 25%
Then one of our team setup a Centos 6 installation and put JIRA onto it. At the first "request" the CPU jumped to 100% and stayed there a long time. He's since run other tests and each time the CPU maxes out.
My own training of VSphere says you shouldn't allocate more than one vCPU to a machine, but increase the cycles if needed, but, if this is what the product needs for just ONE request then it says to me that something is wrong.
I've had our next tier support check our Vsphere environment over and its been given a clean bill of health. They also agree that more than one vCPU would be unusual.
I found a comparison guide:
And the comments seem to suggest that JIRA is just a badly written application for running in VMware.
So - what are other peoples experiences? Do you run JIRA in VM? If so, what resource do you allocate ?
Most of the Jira installations I look after are running on virtual machines, and they're running fine. To be fair, they aren't heavily used (couple of hundred users at most, less than 50k issues).
Where I'm aware of the underlying VM service, it is ESX or Xen based VMs, with RedHat, CentOS or Suse as the hosted OS, so I can't really speak for vSphere.
As far as I can tell, we effectively consider them the same as physical machines. Jira is heavy on the memory and can demand a lot from a CPU as well, so they're all running with 2Gb - 6Gb RAM allocated to the Tomcat (obviously, the VM has yet more). Some have 1 CPU allocated, others 2.
As your CPU is obviously being caned, I'd be tempted to look at the resources you are allocating to it before blaming the VM unfriendly code.
I do agree that Atlassian stuff is VM unfriendly, but to be frank, that's a failure on the part of the people writing virtual machines. Some of the hype about virtualisation is that VMs are supposed to be indistinguishable from a physical machine, and they demonstrably fail miserably to do that - the developers should NOT need to code for the failings of the OS (in the real world, of course, they do, but I do wish virtualisation evangelists would be more honest about their failures)
Hi Nic, thanks for your answer and appreciate your view.
We had an official answer from Atlassian that if we put JIRA into a VM, then they wouldn't support any performance based issues (they would continue config support). That kind of says it all for me, that they've no confidence in virtualising JIRA.
My major gripe is that I can run a full redundant set of exchange servers (4 servers in all), and don't hit these performance issues at all. Obviously its not apples for apples there, but given the bad performance that Exchange is reputated to have, then either Microsoft have something really well (can't bring myself to say that!), or theres something really bad with JIRA.
And to counter your last point, developers should always code effeciently... not assume you can just throw more power at it.. :-)
My last point is still valid - the point about VMs is that they are NOT supposed to behave differently to a real machine. They blatantly do.
Yes, I totally agree that developers should always code efficiently, but part of that is "write once, run anywhere" and that's where VM evangelism fails miserably. If I write something that behaves like X on a physical machine, then when the same stuff is put on a VM equivalent, then it should exhibit behaviour X. That's why Atlassian won't support VMs - there's a very strong chance that the VM is the problem and most, if not all, of their support calls will end up with "sigh, it's the VM again". If it works on a physical server and not on a VM, then it's the fault of the VM, not the developers code.
Hi, we run JIRAs in a VM as required. There's no issues with that. Atlassian run their OnDemand platform in VMs - otherwise how can it be affordable at the price point :)
I would check how many CPUs does Java think it has. In some virtualization environments, we've seen Java think it has all the CPU in the host when there is only 1 allocated and the garbage collection algorithm gets really messed up. It's also the case that might need to allocate more memory than you calculated in some cases too.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG