Do you restart JIRA e.g. once a week? Is it recomended in order to speed it up? Some users using JIRA very intensively are requesting this, realising that the system is slowing down after a certain time.
Thanks for your help!!
I am the Systems Engineer responsible for support.atlassian.com (SAC), a JIRA instance here at Atlassian. While I do have weekly maintenance windows which sometimes require restarts, I try to avoid restarting SAC at all just to keep my up-time numbers high and meet the SLA my managers have set.
Can you provide some context for what you refer to as "very intense use"? I would say the support.atlassian.com site is pretty intense, but I know we have customers who have even more intense implementations out there.
A few days ago JIRA was having a 30 to 60s response time. Instead of restarting the system, I locked and re-indexed it (I was in doubt, if a re-index in the background would bring the same result). After that, the system was responding in up to 10s. But I am neither interested in restart the system very often, nor lock the system for a re-index.
Regular restarts are not the answer! That's just "plastering over the cracks".
You need to work out why it's slowing down and deal with the cause of the issue. I've worked with a number of "intensively used" JIRA systems and not needed (or wanted) to restart them for months (and maintenance is for patches, hardware change or upgrades, never because they're slow). Since version 4, I've been able to nail the "it's running too slowly" symptom to faults in plugins or users doing bad things (like running remote filters for "everything" over REST, or trying to have Agile boards with 10,000 issues for example)
Hi Nic, you have been able to nail the issues causing the system to slow down. You mentioned faults in plugins, as a possible source for such problems. But how to identify them correctly? E.g., is the scriptRunner such a candidate? After using it for a while, my account was terrible affected (but it was already slower as normal).
Script-runnner itself is not a culprit, but oh heck yes, the scripts you can run with it are. It's the reason I don't ever recommend the use of script runner unless you have admins who know Jira well enough to be able to avoid writing scripts that can break it. There are plenty of other plugins that can cause problems, although I would say that most of them are caused by edge-cases, where normal usage of the plugin is fine, but when you try to do something odd, or "clever", then you run into issues which the developers didn't predict. The problem is that there is no easy answer to what the cause is. You need to monitor it, look for patterns, look for the type of slowdown - Something eaten all the memory? Disk IO thrashing? CPU loaded? Run out of threads? Database being thrashed? etc.
The method by which someone who's not an JIRA developer or member of support team can identify the fault in reasonable timeframe and/or tune the instance. Something like https://blogs.atlassian.com/2015/05/webinar-recap-five-secrets-jira-performance-scale/ maybe?
I am facing the same situation with Jose.
If I edit a workflow in a long running JIRA, I need to use a long time to entering the workflow editing page just like condition postfunction. Then it will become very fast after I restart the JIRA.
Some times I will use the "Force garbage collection" function in "System - System Info". It can speed up the JIRA but not effective then restart.
Is that the reason was due to JAVA? Unlike c or c++, the programe running on JVM always have some performence problem, restart the machine may be a way to solve it.
And there is not a hadware problem in my situation because my server has 48GB memroy and I give JIRA 8GB, the cpu is enough for using too (Xeon E5 * 2).
Just throwing resource at a Java system is often not the answer. It is when you're running out, but doing it without *knowing* that low resources are the problem can make things worse. Restarting the machine is the wrong answer too - you need to monitor and investigate what is really happening before you can fix it properly.
You should take a look at access or even use something like New Relic (do a trial - and it's free for a bit ). It will help you see what's going on. I've seen slow down across the system due to caching not really being configured correctly. Another issue has been a third party system overloading the system with requests (iframe on their side etc) which "disappeared" when the restart of my system occurred (and after an hour or so they were back).
Def. look in the lhttp ogs and get some type of live profiling going on that will let you dig into the java classes and see what's the most active.
No, that is the wrong answer - all the answers you've already had are about finding the *Cause* of the slow down, not patching over a flaw. Don't waste your time filling a crack in a wall with a bit of plaster every time it cracks again, when the crack could be telling you "your house is about to fall down"
Sorry, I didn't mean to say "wrong answer" really. It's the "wrong thing to do" - you should not ever automate this. While you're working on the correct thing to do (find and fix the cause), yes, you may need to restart. But if you automate it, you'll be tempted to ignore it because you're seeing less problems on the surface (although probably little improvement because the problem might not even be a leak, and if it's not, restarting at the wrong time won't help you at all). And that's how your house falls down.
Just to add - I have regular restart ( once a week ) automated . Would that cause a problem in the long run ? I believe any application requires a restart time to time . My reason to schedule a restart is because the Database my Jira communicates to gets restarted once a week - and that seems to be creating some errors in my log , so to avoid that . I have also scheduled a jira restart along with the DB .
Taking the database out like that is a good reason for a restart, but yes, it could easily do damage to your system unless you do it correctly. Stop JIRA *properly* (not a "kill") Stop and restart the database Restart JIRA That should prevent problems, as a clean shutdown shouldn't break anything.
I realize this is an older thread, but certainly a relevant issue for us.
We also perform a scheduled weekly stop and restart of Jira, then a lock and re-index. I'm not sure why, and no one could tell me, but I believe it might have been a cache issue. We have over 400k issues in our Jira instance, and the lock and re-index is taking us an average of 45 minutes to an hour. Having an outage of 1 hour/week is not ideal, as our NOC is 24/7 and it interrupts their ability to actively work issues. I anticipate that this will only take longer, as our Jira instance is increasingly growing.
A few questions:
Thanks for any help anyone can provide!
You may have to deal more on linux/windows scripting for your issues here.
Yes. You should not need to restart and stop it. If you are having problems that a restart fixes temporarily, you should be looking at why those problems are occurring, not restarting and ignoring them. There is every chance that they will corrupt your data sooner or later.
Partially, but a restart is the cleanest way to clear the cache. But, as above, you should not need to.
There are some scripts that can do it, but a background index fixes fewer problems than a full index. But, as above, if you're re-indexing because of problems in the index, cache or other faults, you need to be fixing the causes of these, not plastering over the cracks.
Depends on what the root cause of the problem is. There are bug fixes in later versions, but unless you know what the problem really is, we don't know if they might fix what you're running into.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs