0

I have a Debian server (Linode) with 2GB of RAM and 2 CPU cores which I currently use as an email server and web server.

I've recently installed Atlassian JIRA and noticed (with htop) that using JIRA would occasionally cause both CPUs to reach 90-100% usage, especially for about a minute while JIRA starts up.

Is this something that I should be concerned about? If so, what's the best way to limit JIRA's CPU usage?

DanielGibbs
  • 573
  • 5
  • 13
  • 32
  • If you have *contention* then its a concern (other things want the same resource at the same time) as it will double the time it takes for whatever it is contending with to load. However, you be the judge to know if taking double the processing time for a web server to serve up some web content for five minutes is acceptable to you. – Matthew Ife Sep 06 '14 at 22:45

2 Answers2

2

Realistically, how often do you start up JIRA? Shouldn't be more than once per upgrade release. Perhaps once every month? Yes, JIRA and most other large java applications will take up a large amount of CPU when they're starting up. This is just how it is. If it's really a problem, you can look at using the nice utility to give the jvm less priority, but honestly I don't think it's worth it.

Just plan your upgrades for times when the extra momentary CPU contention won't cause issues.

EEAA
  • 109,363
  • 18
  • 175
  • 245
2

Short answer, no, you shouldn't be concerned about it. But you should consider implementing some sort of monitoring capability - sar, nagios, munin, cacti etc and see if it really is a problem.

Generally the best idea is to leave the OS to assign CPU availability.

There are (RARE) cases where this is not optimal and there are lots of tools for configuring the behaviour (nice/renice, cpulimit, taskset, scheduling classes) but first establish that you have a problem and secondly establish whether throttling CPU access is the right solution, Then read up and understand how your scheduler works, then how each of the tools I've mentioned work. Finally try using them in the order I've suggested.

symcbean
  • 21,009
  • 1
  • 31
  • 52