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
Users100500200010000
Active (Concurrent) Users252006002000
Issues15000600002000001000000
Issues/month2001000400020000
Custom Fields50150300600
Permission Schemes3152510
Projects2080200300
Parent Issue Types102050160
Resolutions10203040
Priorities10152540
Workflows5203510
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

 

Thanks

1 answer

0 vote

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
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Julia Dillon
Posted Apr 17, 2018 in Jira

Tell us how your team runs on Jira!

Hey Atlassian Community! Today we are launching a bunch of customer stories about the amazing work teams, like Dropbox and Twilio, are doing with Jira. You can check out the stories here. The thi...

798 views 2 19
Join discussion

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