Jira startup is very slow and it takes a while to start writing to log files
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Jira startup may take a very long time and it also takes a long time to start writing to the atlassian-jira.log file.
Environment
Any version of Jira Core 8.x.
Diagnosis
Capturing a few Thread dumps in sequence, we can see the startup Threads spending a lot of time reading from the filesystem through either FileInputStream or RandomAccessFile classes.
First, we see the localhost-startStop-1 Thread running but with the same stacktrace of file reading:
java.io.FileInputStream.open0(java.base@11.0.15/Native Method)
java.io.FileInputStream.open(java.base@11.0.15/FileInputStream.java:219)
java.io.FileInputStream.<init>(java.base@11.0.15/FileInputStream.java:157)
org.apache.catalina.webresources.FileResource.doGetInputStream(FileResource.java:182)
org.apache.catalina.webresources.AbstractResource.getInputStream(AbstractResource.java:93)
org.apache.catalina.startup.ContextConfig.processAnnotationsWebResource(ContextConfig.java:1916)
org.apache.catalina.startup.ContextConfig.processAnnotationsWebResource(ContextConfig.java:1911)
org.apache.catalina.startup.ContextConfig.processAnnotationsWebResource(ContextConfig.java:1911)
org.apache.catalina.startup.ContextConfig.processAnnotationsWebResource(ContextConfig.java:1911)
org.apache.catalina.startup.ContextConfig.processAnnotationsWebResource(ContextConfig.java:1911)
org.apache.catalina.startup.ContextConfig.processAnnotationsWebResource(ContextConfig.java:1911)
org.apache.catalina.startup.ContextConfig.processAnnotationsWebResource(ContextConfig.java:1911)
org.apache.catalina.startup.ContextConfig.processAnnotationsWebResource(ContextConfig.java:1911)
org.apache.catalina.startup.ContextConfig.processAnnotationsWebResource(ContextConfig.java:1911)
org.apache.catalina.startup.ContextConfig.processClasses(ContextConfig.java:1176)
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1093)
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:779)
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:299)
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5130)
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1427)
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1417)
java.util.concurrent.FutureTask.run(java.base@11.0.15/FutureTask.java:264)
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.15/ThreadPoolExecutor.java:1128)
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.15/ThreadPoolExecutor.java:628)
java.lang.Thread.run(java.base@11.0.15/Thread.java:829)This isn't even Jira — it's Tomcat, the underlying Web Container — starting up.
Second, after maybe several minutes, we see Jira's JIRA-Bootstrap Thread also reading files:
java.io.RandomAccessFile.open0(java.base@11.0.15/Native Method)
java.io.RandomAccessFile.open(java.base@11.0.15/RandomAccessFile.java:345)
java.io.RandomAccessFile.<init>(java.base@11.0.15/RandomAccessFile.java:259)
java.io.RandomAccessFile.<init>(java.base@11.0.15/RandomAccessFile.java:214)
java.util.zip.ZipFile$Source.<init>(java.base@11.0.15/ZipFile.java:1305)
java.util.zip.ZipFile$Source.get(java.base@11.0.15/ZipFile.java:1271)
java.util.zip.ZipFile$CleanableResource.<init>(java.base@11.0.15/ZipFile.java:733)
java.util.zip.ZipFile$CleanableResource.get(java.base@11.0.15/ZipFile.java:850)
java.util.zip.ZipFile.<init>(java.base@11.0.15/ZipFile.java:248)
java.util.zip.ZipFile.<init>(java.base@11.0.15/ZipFile.java:177)
java.util.jar.JarFile.<init>(java.base@11.0.15/JarFile.java:350)
java.util.jar.JarFile.<init>(java.base@11.0.15/JarFile.java:321)
java.util.jar.JarFile.<init>(java.base@11.0.15/JarFile.java:287)
com.atlassian.plugin.JarPluginArtifact.open(JarPluginArtifact.java:197)
com.atlassian.plugin.JarPluginArtifact.containsSpringContext(JarPluginArtifact.java:136)
com.atlassian.plugin.osgi.factory.OsgiPluginFactory.canCreate(OsgiPluginFactory.java:134)
com.atlassian.jira.plugin.MasterPluginFactory.canCreate(MasterPluginFactory.java:50)
com.atlassian.plugin.loaders.ScanningPluginLoader.deployPluginFromUnit(ScanningPluginLoader.java:142)
com.atlassian.plugin.loaders.ScanningPluginLoader.loadAllPlugins(ScanningPluginLoader.java:89)
com.atlassian.plugin.loaders.PermissionCheckingPluginLoader.loadAllPlugins(PermissionCheckingPluginLoader.java:26)
com.atlassian.plugin.manager.DefaultPluginManager.lambda$earlyStartup$5(DefaultPluginManager.java:543)
com.atlassian.plugin.manager.DefaultPluginManager$$Lambda$610/0x0000000800931840.run(Unknown Source)
com.atlassian.plugin.manager.PluginTransactionContext.wrap(PluginTransactionContext.java:63)
com.atlassian.plugin.manager.DefaultPluginManager.earlyStartup(DefaultPluginManager.java:528)
com.atlassian.jira.plugin.JiraPluginManager.earlyStartup(JiraPluginManager.java:119)
com.atlassian.jira.component.pico.ComponentManager$PluginSystem.earlyStartup(ComponentManager.java:671)
com.atlassian.jira.component.pico.ComponentManager.earlyStartPluginSystem(ComponentManager.java:239)
com.atlassian.jira.upgrade.PluginSystemLauncher.start(PluginSystemLauncher.java:45)
com.atlassian.jira.startup.DefaultJiraLauncher.lambda$postDbLaunch$2(DefaultJiraLauncher.java:143)
com.atlassian.jira.startup.DefaultJiraLauncher$$Lambda$267/0x000000080046d440.run(Unknown Source)
com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrEnqueue(DatabaseConfigurationManagerImpl.java:307)
com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrWhenDatabaseActivated(DatabaseConfigurationManagerImpl.java:202)
com.atlassian.jira.startup.DefaultJiraLauncher.postDbLaunch(DefaultJiraLauncher.java:135)
com.atlassian.jira.startup.DefaultJiraLauncher.lambda$start$0(DefaultJiraLauncher.java:102)
com.atlassian.jira.startup.DefaultJiraLauncher$$Lambda$148/0x000000080030e040.run(Unknown Source)
com.atlassian.jira.util.devspeed.JiraDevSpeedTimer.run(JiraDevSpeedTimer.java:31)
com.atlassian.jira.startup.DefaultJiraLauncher.start(DefaultJiraLauncher.java:100)
com.atlassian.jira.startup.LauncherContextListener.initSlowStuff(LauncherContextListener.java:154)
com.atlassian.jira.startup.LauncherContextListener$$Lambda$127/0x00000008002e4840.run(Unknown Source)
java.lang.Thread.run(java.base@11.0.15/Thread.java:829)When JIRA-Bootstrap Thread shows up on the Thread dumps we may finally see some new entries on atlassian-jira.log, but it may still take many minutes for Jira to finally startup and be available through the Browser.
Cause
Neither Jira nor Tomcat are supposed to spend so much time reading from a file during startup. This is a strong lead that something in the server's slowing down Jira's process access to the files it needs to load into memory (jars, classes and all).
This is often a process like some Anti-virus or other file scanning or security mechanism slowing down Jira's filesystem access.
Solution
If such a process or mechanism is actually running on Jira's nodes, the solution is to allow-list Jira's installation and home folder so the filesystem access is not hindered.
For more information on this root cause, please see the Troubleshoot a Jira Server startup failed error KB:
Cause
JIRA applications and anti-virus software are known to be mortal enemies - It's hard to have both of them at the same place at the same time. During startup, JIRA applications create quite a number of temporary files that it has to read from. If an anti-virus software goes through all of these files (which are usually in the JIRA_INSTALLATION or the JIRA_HOME directory), it can hinder or stop the startup process from proceeding normally.
Resolution
Exclude your JIRA INSTALLATION DIRECTORY and your JIRA HOME DIRECTORY from being scanned by the anti-virus. However, sometimes, even though an exception has been added, the problem might still persist, in those cases, please try disabling your anti-virus entirely. Further information regarding the correlation between anti-virus and JIRA application performance can be viewed in this KB - Common causes for Jira Server crashes and performance issues.