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 usersHeavy attachment usage across projectsSeveral 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.
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 🤠
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.