Hi, Currently our JIRA instance has around 48,000 issues. We are migrating from another issue tracking system to JIRA, and upon final cutover we will be having a total of 180,000 issues as of now. As per recent calculations, currently we have a growth rate of approximately 5,000 - 6,000 issues per month. Since Atlassian has recommended splitting up JIRA upon 200,000 issues, we are planning and studying the feasibility of doing so. * Our database is hosted on a separate server. Does this help us to survive beyond 200,000 issues without splitting? * If we split the instance, is it possible to make the split instances available on the same URL?* One of our major concerns is that we often link issues belong to different projects. Can we maintain these links after splitting? * If we split the instance, can we run both on the same physical host by just doing a memory upgrade? * Is there a possibility to have two (or more) instances in sync and implement load balancing? * If splitting is not feasible, what are the other options to keep a large sysetm stable? Thanks in advance! -- Shaakunthala

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Splitting a JIRA Instance

Sameera Shaakun2

Hi,

Currently our JIRA instance has around 48,000 issues. We are migrating from another issue tracking system to JIRA, and upon final cutover we will be having a total of 180,000 issues as of now. As per recent calculations, currently we have a growth rate of approximately 5,000 - 6,000 issues per month. Since Atlassian has recommended splitting up JIRA upon 200,000 issues, we are planning and studying the feasibility of doing so.

Our database is hosted on a separate server. Does this help us to survive beyond 200,000 issues without splitting?
If we split the instance, is it possible to make the split instances available on the same URL?
- One of our major concerns is that we often link issues belong to different projects. Can we maintain these links after splitting?
If we split the instance, can we run both on the same physical host by just doing a memory upgrade?
Is there a possibility to have two (or more) instances in sync and implement load balancing?
If splitting is not feasible, what are the other options to keep a large sysetm stable?

Thanks in advance!

Shaakunthala

Accepted answers

Nic Brough -Adaptavist-

1. Not really - the database size is not the problem, it's the internals of Jira on the application server.

2. Not yet. I think the Atlassian "Jira Enterprise" team are looking at this sort of thing. Version 5 does support some jira -> other-jira linking, although I've not tried it, so I'm fuzzy on the detail.

3. Yes

4. No. Jira doesn't do clustering and hence can't support load-balancing

5. Faster hardware, memory tuning.

I should also say that almost all of the Jira installations I've worked with are over the 200,000 and mostly working ok - you can get away with throwing better hardware at the problem for a while, and later versions of Jira have improved the handling of larger datasets.

All comments

Nic Brough -Adaptavist-

1. Not really - the database size is not the problem, it's the internals of Jira on the application server.

3. Yes

4. No. Jira doesn't do clustering and hence can't support load-balancing

5. Faster hardware, memory tuning.

Sameera Shaakun2

Hi Nic,

Thanks for the answer. I think under these considerations it's better to proceed the same single instance, with proper hardware and tuning.

Nic Brough -Adaptavist-

It can be - I'd also look at agressive housekeeping (e.g. take a backup xml, keep it safe, and delete old/unused projects - if someone does need them, you can spin up a temporary Jira with a development license - I think that's acceptable under the license as long as you don't leave it running).

Atlassian have recently put together a team to look at "enterprise customers". That's not quite the same as "customers with large numbers of issues in their Jira", but the two groups overlap a LOT. That should give us a few more options soon.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

performance