Reduce the number of active Assets objects
This recommendation is shown when we've detected that the number of Asset objects in your Jira instance is approaching or exceeding recommended limits, and JVM memory is consistently saturated. A large number of active objects increases the memory footprint of the Assets index, which can reduce both Assets and wider Jira performance.
Signals used
Details of how we detect this issue.
Conditions
The following conditions need to occur together:
JVM memory is saturated - memory usage is consistently high across the cluster.
The Asset object count is close to or has breached the recommended guardrail.
We identify specific Asset schemas with the highest object or object type counts that are contributing most to the problem.
Optionally, we also consider whether the Asset schema count is close to its guardrail, and whether AQL slow query events are increasing.
How we detect it
Signal | Details |
|---|---|
JVM memory saturation | We monitor JVM heap memory usage across the cluster. The signal checks whether the p90 of memory usage exceeds 80% and whether the saturation is sustained. |
Asset object count guardrail | We check whether the total number of Asset objects in the instance is at or above 90% of the recommended guardrail. A very high object count increases the memory footprint of the in-memory Assets index, leaving less memory available for other Jira operations. |
Asset schema count guardrail | We check whether the total number of Asset schemas is approaching the recommended limit. A high schema count combined with a high object count can compound memory and performance issues. |
Asset schema analysis | We analyze individual Asset schemas to identify which ones are breaching (or close to breaching) per-schema guardrails. If any schemas breach these limits, we highlight them. If none breach, we highlight the schemas with the highest object counts. |
AQL slow query events | We monitor whether AQL (Assets Query Language) slow query events have increased. A rise in slow queries suggests that the Assets index is struggling with the volume of data, and that users may be experiencing slower search and filter performance. |
Filters
When this issue occurs multiple times, we group occurrences under different time filters, for example a 24‑hour or 7‑day period. In this case:
For degraded experiences, we show the highest degradation from all occurrences in the selected time filter.
For data and limits, we highlight the highest numbers of particular entities from all occurrences.
Frequency chart
The frequency chart shows how often this issue has occurred over time. This can help you identify patterns such as:
periods when your instance regularly approaches or exceeds Assets object guardrails
whether past clean‑up or archiving efforts reduced how often this recommendation appears
Recommended actions
Review Assets sizing and guardrails
Start by checking how your current Assets usage compares to recommended limits.
Review the system requirements for your Jira version and instance size.
Additionally, you can check the Jira Service Management guardrails for Assets object and schema counts to understand whether your current usage is close to or beyond the suggested limits.
If your instance is near or over these guardrails, it’s more likely that high object counts are contributing to performance issues.
Archive objects in large schemas
To reduce the memory footprint of Assets and improve performance, focus on the largest schemas first. Identify objects that are no longer actively used but still kept as active records (for example, old hardware, retired services, or historical configuration items).
Archive these objects so they’re removed from the in-memory index, freeing up memory and reducing the load on indexing and queries.
If you have AQL queries that can identify “stale” objects (for example, objects not updated or referenced in a long time), use them to find good archiving candidates.
For details, see Archiving an object.
Was this helpful?