-
Bug
-
Resolution: Incomplete
-
Low
As noted in Lexorank support Tools page :
A rebalance will start (within a minute) and complete the failed balance, majority of issues with long rank values will be rebalanced. At this point there may still be issues with long rank fields, and a second re-balance may be required. After the completion of a second rebalance, the rank system will enable ranking operations.
I many cases the Rank Rebalance does not Occur, and the max_rank_string_length value increases causing high CPU load on the system whenever an issue with a large value is referenced, either in an agile board or the ticket directly, in many cases leading to a System outages due to load.
If a timeout occurs you will see the following in the logs:
[greenhopper.customfield.lexorank.LexoRankIndexer] Could not retrieve LexoRank value for issue[id=jiraIssueID]. Indexing max LexoRank value instead.
Majority of the time no indication of the issue are visible until timeout occurs.
UPDATE:
We have been able to narrow this down to the following two conditions:
- max_rank_string_length is high
- Number of issues in Agile field_id Also HIGH
When both of these values are at increased levels the performance hit occurs until the max rank value is balanced.
- EXE. a heavily used Agile Board
Workaround:
Follow the steps in this Knowledge Base Article.
emccutcheon as per our conversations some time ago, I am going to close this bug because there's nothing actionable here from the developer team.
If we see that customers are experiencing performance degradation around the ranking system, we will first need SSE/DOS to investigate and find the root cause or at least clearer symptoms.
Regards,
JIRA Agile team