Persistent, widespread performance degradation (slow page loads, slow search/board rendering)

[John Smith]

Persistent, widespread performance degradation (slow page loads, slow search/board rendering) on a single-node Jira Software 9.12.13 Data Center instance used company-wide across Development, CRM, HR, Commercial, and Finance teams (~500–2,000 users).

Our Jira Software Data Center 9.12.13 instance (Jira Core 9.12.13, Jira Service Management 5.12.13, Confluence 8.5.15) is experiencing recurring, widespread performance degradation — slow page loads, slow issue navigator/board rendering, and slow search — reported by users across all departments (Dev, CRM, HR, Commercial, Finance) that rely on this instance for their core workflows.

Environment:
Single-node Data Center deployment (not clustered)PostgreSQL database

~500–2,000 licensed users

Heavy attachment usage across projects

Several apps installed, including Timepiece – Time In Status and eazyBI

We are not able to change our platform/tooling — we need guidance on tuning, scaling, and capacity planning for our current Data Center deployment (e.g., whether our single node is undersized for this user count/workload, JVM/heap and GC tuning recommendations, database tuning, attachment storage best practices, and whether moving to a clustered DC deployment — which stays within our current licensing — would meaningfully help). We'd also appreciate guidance on how to identify whether any installed apps are contributing to the slowdown.

We understand Jira 9.12 has passed its DC end-of-life date; we're (slightly) open to upgrade recommendations as part of the fix [prefer not to, though], but need this decoupled from a "just migrate to Cloud" answer since that's off the table for us.

[Arkadiusz Wroblewski]

Hello @John Smith

With the scope of the degradation you're describing, I wouldn't recommend making JVM, database or clustering changes based only on suggestions from a Community thread.

Adding nodes won't help if the bottleneck sits at the database or storage level.

Collect diagnostic data (Support Zip, thread dumps, GC logs) and have Atlassian Support or a Solution Partner run a formal assessment. Also note that Jira 9.12 reached EOL in November 2025, so plan an upgrade to a supported Data Center version.

For a company-wide Data Center instance supporting many business-critical workflows, a proper performance assessment of the actual installation is the appropriate next step. 

We have too less information.

Best,

Arek 🤠

[Martin Runge]

Hi @John Smith

I am 110% with @Arkadiusz Wroblewski that the Support Zip, thread dumps, and GC logs come first, and that you should not turn off a thread. On top of that, here are the Jira levers I'd have those diagnostics confirm, because they map straight to slow Navigator, board, and search.

The first place I'd look is the Lucene index and check index health and, if it looks off, run a background reindex from ⚙ > System > Indexing in a quiet time window.

The other high-chance win I'd chase is custom field bloat. Every custom field with a global context gets evaluated across all issues. I'd review them under ⚙ > Issues > Custom fields and use the Custom Field Optimizer to spot fields you can scope down for only some projects or even remove altogether. This alone often gives a noticeable lift.

To answer your app question directly: I'd line up the slow periods against eazyBI import times, or even temporarily disable each app in a maintenance window to see if the slowness tracks with one of them.

Are the slow periods fairly constant through the day, or do they spike at certain times, such as overnight or on the hour when scheduled jobs and imports tend to run?

Cheers, Martin

[Arkadiusz Wroblewski]

@Martin Runge, also 100% behind your answer.

That needs some assessment to determine what is really causing it.

[Gabriela - LeanZero]

Hi John,

Arek and Martin are right that the diagnostics come first, and I'm not going to hand you heap, GC, Postgres or attachment-storage values off a forum post either, since those need numbers from inside your instance. But nobody has taken your clustering question head on yet, and for your setup I think it has a specific answer.

Clustering is probably worth doing, though not for the reason it usually gets sold. Take the per-request case off the table first. Atlassian's own performance and scale report inside the 9.12 docs runs the same test on one node and on a two-node cluster, same node hardware, database on a separate box, and the cluster comes out slower on all ten data dimensions: 559 ms against 544 across all datasets, 567 against 544 on the attachment set. That run is 20 scripted browsers at zero think time on MySQL, so it is a low-load calibration and nothing more. What a second node buys, in Atlassian's wording, is concurrent user capacity and failover.

The reason it applies to you is eazyBI, which is also where I'd push Martin's timing question hardest. Its Data Center mode lets you nominate dedicated nodes, and its own docs say why: "For large Jira Data Center installations it is recommended to have a separate cluster node (or several nodes) that are not used by the load balancer for incoming user requests", with manual and scheduled imports running only on those nodes. On a single node you can't do that, so eazyBI's imports and cube queries compete for the same JVM your users are waiting on. Atlassian's KB for that app describes the signature as heap spikes plus database read spikes at the same time each day, from its scheduled imports. That KB is written against 8.x, but the shape holds. If the slowness does spike on a schedule rather than sitting flat all day, that's the thread to pull.

Get the numbers before you buy hardware. Jira 9.12 has per-app JMX metrics, on by default unless an admin turned them off, under System then Monitoring. They come back keyed by plugin key, which you resolve at /plugins/servlet/upm/osgi. That gets you app attribution without needing the maintenance window Martin mentioned. The diagnostics plugin is separately keeping 30 days of alerts in the database, and the one matching slow search is the slow JQL query alert, 400 ms by default. Don't lean on DB-3001 slow HTTP request for ordinary slow page loads; it only fires above 60 seconds.

On sizing, 500 to 2,000 users straddles Small and Medium on Atlassian's size profiles, and the overall profile is generally dictated by whichever single metric registers highest, so collect all nine of them. That page also says the bands apply only where the database runs on a different machine. If PostgreSQL sits on the same box as Jira, none of the published sizing describes you.

One upgrade note that stays inside your constraint: the 9.12 line is still getting releases. 9.12.38 landed on 6 August, and you're on 9.12.13 from 4 September 2024.