How do I can calculate the size on disk based on the issues raised?

How do I can calculate the total disk space for the database on the issues raised?


I have the following table

izing LegendSmall-scaleMid-scaleLarge-scaleEnterprise scale
Application usage
Active (Concurrent) Users252006002000
Custom Fields50150300600
Permission Schemes3152510
Parent Issue Types102050160
System levelsmall scalemedium scalelarge scaleenterprise scale
System Requirements
DescriptionFor this low level server, consider a dual core type CPU and fast, physical hard disks.For a medium level machine, consider using a medium server CPU (e.g. quad core) and high speed hard disks (e.g. 7200RPM+) for the home directory and backups.For a high-level system, we recommend using high processing power (e.g. dual quad core or higher) and ensuring high I/O performance, e.g. through the use of 10,000+ RPM or Solid State Disks.This should be a top of the line server with enterprise grade processing power (e.g. 6 quad cores or more) and the highest possible I/O performance (e.g. Raid 10, Solid State Disks).
System Memory8GB> 8GB> 16GB>128GB
JVM Heap Size> 1GB> 2GB> 4GBConsult our experts
App Install Dir~200MB~200MB~200MB~500MB
Backups> 100MB> 200MB1-5GB10GB
Attachments10 - 50GB50-100GB100GB400GB
Application Logs25MB50MB100MB250MB
Total disk space10 - 50 GB50 - 100 GB100-200 GB> 500 G



1 answer

0 votes

You can't do it from that information.

Looking at the base unit of a single issue, you'd need to look at every single issue to establish what fields it has, and how big each field is.  Some are fixed size (e.g. a date/time stamp), but some fields can be free text, in which you could write unlimited text.  Even if you make assumptions about how big an average text field is, one issue type might allow no free text, and the next one has ten of them.  You've also got the fun of attachments which live on the disk and can be quite large or numerous, or simply not exist.

In other words, the disk space you need is a function of ( the number of issues you have * complexity of config + attachments).  That complexity is so variable, you might as well forget it.

Now, having pointed out that you've got too many variables to even begin to make an estimate of size, there is a really simple way to think of this:

  1. Databases are reasonably good at storing data - not compressing it necessarily, but being efficient with it.  Don't bother worrying about database space - the largest JIRA database I've seen was a handful of GB, and it was bigger than your "enterprise" column
  2. Your attachments are far more likely to cause you disk space issues.  All you need is decent space monitoring though.


Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,655 views 18 21
Read article

Atlassian User Groups

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!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you