nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How To... reindex policies?

llagos

Hi Community,

Our system is behaving really slow lately, and the solution given to us by the provider is just to "reindex" the whole thing... however, this implies downtime, as the background reindex takes more than 3 hours, and really doesn't reduce times... so an offline reindex is the proposed solution...

Now, the proposed solution for the provider is the totally stop JSD once per week or every 2 weeks, do an offline reindex, then start JSD again... and in the meantime, keep a daily background reindex running as well...

So, I wonder, how does other systems do? Our system is a standalone server, with no more than 20 concurrent agents working on tickets at once... really small compared to other big "enterprise" solutions... we're a small company...

Accepted answers

All comments

Alexey Matveev

Hello,

You can setup Jira Data Center, in this case you can reindex Jìra node by node. Reindex usually is done after major changes:

https://confluence.atlassian.com/adminjiraserver074/re-indexing-after-major-configuration-changes-881684033.html

If you have not done major changes, then you should not reindex Jira.

I guess, in your case somehow indexes are not rebuilt without major changes. I would try to find the reason. It could be an add-on, which you use.

Nic Brough -Adaptavist-

I doubt re-indexing is going to help much. If your index is damaged or full of bad data, it can, but you should be looking at how that happened, so you can stop it.

Re-indexing regularly is just going to put more load and downtime on your system when you really don't need it.

Regular restarts with "offline indexing" is nonsense, the system has to be running for the indexing to run. Regular restarts might patch over a memory leak, but rather than messing about with that, you should be looking for the cause of the memory leak.

There are two things I would look into:

Fixing the speed - take a proper look into what the root problems are, rather than tinkering with the symptoms
If you want to continue to just patch over, what Alexey said!

llagos

Thanks Alexey, Nic..

We are heavily using Insight for a CMDB style db, plus other things, and also Insight scripts. When I say "heavily" it's because there are several validations whenever an issue is created and even when it's edited/transitioned. Just creating an issue takes about 7s.

We'll look into it but I haven't found a tool for "profiling/auditing" the times involved. Is there such a tool?

What about tuning the reindex? I found a property for v7 that is related to this under Advanced Settings...

jira.index.background.batch.size: The number of issues to read from the database at once during background indexing.

Default it's 1,000...

Thanks again,

Alexey Matveev

What is the connection between issue creation for 7 sec and background reindex? During this 7 seconds the issue is reindexed. You do not need a background reindex.

llagos

According to our provider, when an issue is created, a lot of scripting and double checking is performed, both in Insight, and so, a lot of time is lost reindexing this issue.

I'm far from knowledgeable in JSD, so the word of our provider is the only word we have...

that's why I ask for opinions here

Thanks!

Alexey Matveev

I still do not understand why you have to stop Jira for full reindexing. Reindex is done upon issue creation and you should not do another reindexing

Regarding not good performance during issue creation, you should optimize your code on issue creation.

Nic Brough -Adaptavist-

I am not sure why you are so focussed on the index.

The index is a copy of your database, organised in a totally different way - it is designed to enable Jira to find issues fast. It is a set of local files that enable searching to be massively faster than running hugely sub-optimal SQL on a remote database.

The index is only a direct cause of load when you are reading it (using searches or reports that draw on its data), or writing to it.

The read side is totally unavoidable - it is almost all of what your users do, but it is relatively fast (local files, caches, optimised for what they do etc).

Writing to it is nowhere near as fast as reading, but it is only done when an issue is re-indexed. This happens when an issue is changed, or when a batch of indexing is asked for (re-index in the background or foreground, or re-index project), but even the batch is just "re-do index for each issue in turn".

So, when you say your system is slow, the index is not going to be the problem, unless you've stuck the files it is made up of on a painfully slow disk. Re-indexing in full can help performance a bit, but only when your index is actually damaged!

You have re-indexed, and still have slowness, so it is not damage to the index, it is something else causing the slowness. You need to look at that.

7 seconds to create an issue for example - implies you are trying to do too much during creation, or the code that you've got is not efficient.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-service-desk

jira-server

jira-service-desk-server