I've read https://confluence.atlassian.com/display/JIRAKB/Export+More+Than+1000+Results+to+Excel?continue=https%3A%2F%2Fconfluence.atlassian.com%2Fdisplay%2FJIRAKB%2FExport%2BMore%2BThan%2B1000%2BResults%2Bto%2BExcel&application=cac , https://confluence.atlassian.com/display/JIRAKB/OutOfMemory+or+Poor+Performance+due+to+XML+View+of+a+Filter , and https://confluence.atlassian.com/display/ONDEMANDKB/Export+More+than+1000+Issues+to+Excel+from+Issue+Navigator+in+JIRA+OnDemand .
As the report I need to export is ~60k+ rows, my IT department would like to know what kind of load this will place on our JIRA instance. We plan on comparing any information provided against the system properties of our server and using this information to schedule a time where I can export my information.
many thanks
It'll render your JIRA useless for a while, and then crash. It's too much, it won't cope unless you have stupid amounts of RAM allocated.
Maybe he can spread his export in a bunch of bulked JQL searches to avoid overloading his instance?
what do you define as "stupid amounts"?
I'd start with 16Gb and not bet on it being enough. I think the right option is to ask why you're trying to do an export that JIRA deliberately and explicitly limits, and do it properly instead of trying to bodge it.
Yes, 1000 at a time, it's a sensible limit. It's there for a very good reason. What he's trying to do is wrong.
@Benito Picarelli, I appreciate you trying to help. It seems like JIRA has indoctrinated in some that large exports are unnecessary?
@Nic Brough, If you have other recommendations on how I can pivot and analyze my data, I'm all ears. The tools I have that will allow me to crunch this in combination with my other datasets exist outside JIRA (tableau, excel, etc)...
You can export to Excel for further analysis with the Better Excel Plugin although it will also put quite some load on your JIRA.
Tips to reduce the load:
Further tip:
I can't do much with a vague story like that. What question(s) are you actually trying to answer?
I'm answering what degree of case load my team has worked, by issue and subissue; and by agent; and our adherence to SLA; and a host of other questions. I'll combine this with outside data as well; which is why it cannot be done within the JIRA reporting structure.
So instead of doing random static and instantly obsolete reporting, you should be concentrating on writing something that draws data from your other systems and combines it with the RELEVANT Jira data (not extracting the whole lot and wasting time discarding 99% of it every time). Or just install Jira service desk and probably junk your other system
It looks like you're new here. Sign in or register to get started.
