The Jira Settings that Can Cause Jira to Crawl

You’ve got a Jira server running on the perfect environment. It lives on its own ESX server, and it has been allocated a dozen CPUs, 40 GB RAM, a terabyte of lightning-fast fiber-connected SSD storage space, and enough network bandwidth to stream an actual stream. Your authentication is on a remote Active Directory server, your database is on a dedicated remote server, and the ping time between them is so low that they might as well be sharing a hard drive.

So why is Jira crawling?

The answer may be in the last place you’d expect: the database. Jira is really good at self-configuration. After 15 years and 7 major versions, Atlassian has polished the installation, upgrade, and configuration processes to the point where you barely need to think about your database. You feed the wizard a driver, a URL, and some credentials, and JIRA takes care of everything. It’s pretty awesome…until it’s not.   

Your Jira database may be misconfigured

Simply put, as your Jira instance grows, your database has to adapt. If your database is misconfigured, throwing hardware at the problem won’t help. If JIRA is crawling and you’re trying to figure out why, before you open the can of worms associated with throwing hardware at the problem, I strongly recommend that you have a look at your database configuration.  

For example, if you’re a MySQL user:

Way down deep in Jira’s my.cnf and dbconfig.xml files, you’ll find a bunch of Jira settings with arcane names like “innodb_flush_log_at_trx_commit,” “innodb_buffer_pool_size,” and “min-evictable-idle-time-millis.” These variables define how your database will behave. Your hardware may be capable of handling a Jira instance with 200,000 issues and 30,000 users across 1,000 projects, but if your database is set to limit itself to 100 connections at a time, Jira is still going to crawl!  

You can get a lot of mileage out of understanding a few key parameters…

  • innodb_buffer_pool_size: The buffer pool is where innodb holds data and indexes in RAM. If it’s set too low, your database will have to do disk reads to find your data. If it’s set too high, the rest of your application will be starved for RAM. Opinions are divided as to where the sweet spot lies, but it’s somewhere between “a little more than the total size of your database” and “all you can spare.” 
  • max_connections: If you’re getting “Too many connections” errors, odds are this is your root cause. Again, it’s a balancing act. If your application doesn’t close connections correctly or you have a high-traffic application, you’ll run out of connections fast. That said, if you set your max_connections too high, your server can hang because it has thousands of transactions to service. 
  • innodb_log_buffer_size: Despite the name, this has little to do with logging. The log buffer is where innodb stores transactions that haven’t yetbeen committed. If you have big wodges of text being written to the database, the buffer can fill up fast.  

As always, your mileage may vary depending on your specific Jira configuration. What works for one system may bring another to its knees. Ergo, you should test things out on a staging server before pushing to production…and it is always wise to make a backup. Each database technology that Atlassian supports has its own tuning parameters that you can adjust to suit your needs. It’s well worth spending some time reviewing your Jira settings to ensure the best possible performance!