How do I can calculate the total disk space for the database on the issues raised?
I have the following table
|izing Legend||Small-scale||Mid-scale||Large-scale||Enterprise scale|
|Active (Concurrent) Users||25||200||600||2000|
|Parent Issue Types||10||20||50||160|
|System level||small scale||medium scale||large scale||enterprise scale|
|Description||For 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 Memory||8GB||> 8GB||> 16GB||>128GB|
|JVM Heap Size||> 1GB||> 2GB||> 4GB||Consult our experts|
|App Install Dir||~200MB||~200MB||~200MB||~500MB|
|Backups||> 100MB||> 200MB||1-5GB||10GB|
|Attachments||10 - 50GB||50-100GB||100GB||400GB|
|Total disk space||10 - 50 GB||50 - 100 GB||100-200 GB||> 500 G|
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:
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...
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!
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