1 / 2 indexing threads configuration
Mostly SVN repos, some Git
Since our recent upgrade to 3.7.1, Fisheye has gotten into a state where a few threads will run constantly, saturating the CPU. After a restart, it calms down and then after some time, hours or days, will abruptly consume all of the CPU cores again (and not let go).
Fisheye is usable right now (after a restart) but there has been one constant thread consuming one CPU since the restart. What is its purpose? When the CPU cores become saturated, and Fisheye becomes unusable, there are several of these similarly-named threads competing for CPU:
qtp1351478315-1318  (RUNNABLE)
com.cenqua.fisheye.diff.MyersOND.buildPath line: 123
com.cenqua.fisheye.diff.MyersOND.diff line: 82
com.cenqua.fisheye.diff.Diff.diff line: 8
com.cenqua.fisheye.diff.DiffHelper.getHunkList line: 27
com.cenqua.fisheye.diff.DiffHelper.getHunkList line: 142
com.cenqua.crucible.revision.source.Source.getHunkList line: 230
com.cenqua.crucible.view.FRXDO.getHunkList line: 1287
com.cenqua.crucible.view.FRXDO.getTetrisGrid line: 781
com.cenqua.crucible.view.FRXDO.mapInlineComments line: 809
com.cenqua.crucible.view.FRXDO.<init> line: 204
com.cenqua.crucible.revision.managers.DefaultContentManager.makeFRXDO line: 114
com.atlassian.crucible.actions.ReviewBaseAction.makeFRXDO line: 597
com.atlassian.crucible.actions.ViewFRXAction.execute line: 188
GC is not an issue, not even when Fisheye becomes non-responsive. We have a 16G heap that collects down to 6G and there is no thrashing (of GC).
What is the purpose of this thread? Can we correct something to remedy the CPU utilization or is it necessary to assign more processors to this machine?
More information: these threads start taking a full CPU core when a particular file is viewed in a review. The file is never viewable and the UI eventually times out. However, the thread never goes away. If we try to view that file in a review again (new window), a new thread pops up taking a full CPU core. Now we have 2X threads each taking up full CPU cores. We can keep doing this until the instance becomes non-responsive. The offending file is an xxx.sql file (with SQL content). We don't immediately see anything suspicious about it.
As Sergey mentioned from your description and stack trace it looks you're facing the issue described by https://jira.atlassian.com/browse/CRUC-6593, though you mentioned it happens even not loading any of the files.
For the review in which you observe this happening can you please confirm:
I've also asked for updates in CRUC-6593 in a private comment - please add yourself as a watcher to it so you can keep track of any progress on it.
...word of mouth, so by 2016, we were working with several other entities on campus to implement Jira Service Desk . The Atlassian motto of “for every team” has really come true for us in this case. We...
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot