@mlassau the comment at https://jira.atlassian.com/browse/JRA-38598?focusedCommentId=653398&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-653398 showed a significant reduction in the reindexing time based on changing the number of threads. Perhaps the DB read actually is a bottleneck

Good to know about jira-config.properties. We will test for performance differences next time we upgrade. This issue really is resolved.

For background re-indexing, those of us with high up-time requirements have been depending on the JIRA Script Runner plugin which has allowed background reindexing of arbitrary sets of JIRA tickets for years. I will inquire with that author about the behavior with respect to the new property setting.

Thank you for updating this issue promptly!

This issue is asking for the number of threads to be tunable...

We added a property called "jira.index.issue.threads" to jira-config.properties that affects foreground reindex.

We intentionally made the background reindex run in a single thread because, well, its running the background, and we want to limit the performance degradation for other parallel operations.

... even when Background re-indexing.

Really? This issue was raised before Background reindex was a reality, so I am going to have to disagree with you

Modern servers have far more than 10 cores, so why limit the reindex to 10 threads?

Like I said in a previous comment, the Lucene writer is single-threaded (see eg http://lucene.472066.n3.nabble.com/IndexWriter-multithreaded-td569696.html).
The 10 threads are only reading from the DB to feed the single Lucene writer thread, so I doubt if increasing that number is going to help anyway.

I just noticed that this issue was resolved along with JRA-7842, but this issue is completely separate. This issue is asking for the number of threads to be tunable, even when Background re-indexing. Modern servers have far more than 10 cores, so why limit the reindex to 10 threads?

Can this be reopened?

daved: The reindex choice is presented as:

There is no "Are you sure?" double-clutch, but it does make it reasonably clear that the operation may take a while and that the instance will be unavailable during that time. Reindexing itself is also much faster in more recent versions of JIRA.

Hi - We've just been bitten by this "foreground reindex" issue for the 3rd time: the link to kick off a reindex in v4.4.5 starts the reindex with no "Are You Sure?" message. New Jira admins see the message saying that a reindex is needed, and they click the link. (Now, why we hire people who will press a button on a major system without knowing what it will do is another question...)

But anyway, this has happened to us at least 3 times over the past 5 or 6 years, and it takes Jira offline for a couple of hours in the middle of the day! Not cancellable! MAJOR pain in the neck! The whole thing could easily be mitigated if the process first presented a message that says, "This will take Jira offline for the duration, and may take hours. Are you sure you want to do this?"

In Mark Lassau's comment from 04/Jul/12, it says, "The admin has the choice of the two options when they start the reindex and the background re-index is cancellable."

I hope the design includes some kind of "Are you sure?" message for the foreground option.

Hi,

Great thanks for the background reindex !!!

Regards,
Sven.

Also, FWIW, our current re-index rate is in the 250 to 300 issues per second range for foreground re-indexing. I don't have good numbers for background re-index performance with the Script Runner plugin.

I can move this request to a separate issue, but operationally the difference between reindexing the whole instance, which could take hours, and reindexing just a few hundred or few thousand issues, which would take minutes, means the difference between something that can be done during business hours vs. something that may have to be done on a weekend in order to avoid prolonged performance issues and/or unavailability of data.

When tickets are imported from other issue tracking systems, especially if we're massaging the data in the database after import

This makes sense if you are manually massaging issues in the DB.

Changing the value of a custom field across all tickets

In this case you would want to do a full re-index (or at least for all projects that use the custom field which suggests more than a few hundred issues)

Changing the type of a custom field (select-list to multi-select list, say)

In this case you would want to do a full re-index (or at least for all projects that use the custom field which suggests more than a few hundred issues)

Recovering from a JIRA crash where the index has become corrupted for a handful of tickets

Do you actually know which issues the index is corrupted for so you can limit the re-index? How?
It seems to me that for this case you would be better off to do a full background re-index?
Perhaps you want a "selective" re-index to fix the high priority issues that were spotted ASAP, followed by a full re-index to clean up the ones you haven't noticed?

Anyway, at this stage I should suggest you open a separate improvement request where we can gather this information...