-
Bug
-
Resolution: Fixed
-
Medium (View bug fix roadmap)
-
6.2.3, 6.3-OD-2
-
None
-
6.02
-
NOTE: This bug report is for JIRA Server. Using JIRA Cloud? See the corresponding bug report.
Summary
When a JIRA Instance has many Security Levels the performance of JIRA can degrade significantly.
Steps to Reproduce
- Configure an environment with many Projects and Issue Security Configuration.
- Observe a degradation of performance on the instance.
- Thread dumps from an affected JIRA instance may indicate many threads showing a stack traces involving IssueSecurity.
Expected Results
JIRA should remain performant and cope with the scale in issues or issue security.
Actual Results
JIRA becomes unresponsive with large numbers of issue security levels configured.
Notes
Configuring Issue level Security currently indicates thar setting more than 10 issue security levels can impact performance in JIRA.
Workaround
- Run the following SQL to check the number of security level:
select scheme, count(security) from schemeissuesecurities group by scheme; scheme | count --------+------- 10000 | 1279 10030 | 3 ... (7 rows)
- Reduce the issue security levels.
- Reduce the number of groups using in each level.
- is duplicated by
-
-
- Closed
-
- is related to
-
JRASERVER-44277 Create Limits and Warnings on too many Issue Security Levels
- Closed
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
JDEV-28164 Failed to load
-
JDEV-29227 Loading...
- causes
-
- included in
-
CPU-302
JIRA 7.2.0-OD-01-028
- was cloned as
-
[JRASERVER-38136] JIRA performance degrades when a large number of security levels are used
ed letifov
1) The ability to mitigate this is already present in the shipped version since JIRA version 6.2.5.
2) The size is linear with respect to the number of entries in the "schemeissuesecurities" table, which is a combination of the size of levels/projects/etc but not a direct product, so should be greater that that. Making it very big will not hurt, as it will only grow to the size required. The new code has a different strategy for sizing and expiration which should scale without problems.
Trevor, can you please confirm:
1) that the ability to mitigate via cache size change in the file is the change currently to scheduled to be available in 7.0.10 (as per fix versions) as opposed to something that already exists in versions before that
2) that the dependency between mitigating cache size and the number of security levels is indeed linear? should the size be greater that TOTAL number of security levels in the instance or is this per project? During the initial investigation of the issue we've reported via support ticket someone mentioned that the actual dependency is "number of levels" x "number of projects" x "number of users" or something similar i.e. exponential and unrealistic with big number of users AND levels AND projects hence the "not more than 10 levels please" limitation. Can you please confirm that this is not the case with the new code?
This can be mitigated by setting the value
jira.security.level.permission.cache.max.size = 10000
in the jira-config.properties in the jirahome directory. You may need to create the file if it does not already exist. You will need to restart JIRA for this to take effect.
The size to b set should be greater than the number of issue security levels.
The root cause seems related to the limit placed on the size of the issue security cache.
AMAZING WORK! ABSOLUTELY AMAZING!!!
JIRA here is about 10x faster now! You my friend deserve a major raise!
High five!