I have a crucible instance running over a single SVN repo. It has historically worked, recently it has started failing to index. I have tried reducing the number of revisions to even the single most recent entry and it is failing to index. It scans all revisions easily, but sticks at the start of the idex process.
I have tried index, full reindex, manually deleting the whole index and I get the same issues. It appears to just get stuck and eventually Java just uses all the memory on the box until no-one can get in at all.
I would look at your heap size and object allocation using an APM tool or heap analyzer.
Do the logs indicate any errors before it crashes?
It may be a big revision is causing a number of objects to force excessive Garbage Collection. You can try increasing heap, but I would only suggest that if you see memory issues.
Which changeset is it getting stuck on ?
Can you please have a look at that changeset, and see if it involves many many paths ? How many ?
Also be aware that we are fixing such issues with FishEye all the time, and the most recent version of FishEye/Crucible 3.3.2 should be used. 3.4.0 coming out in mid-April will also contain improvements in the area of indexing extremely large changesets.
Further, you could send the java process a SIGQUIT (kill -3) to get a couple of heap dumps and see what is happening prior to the OOME.
Also, you could capture a MemoryDump on OOME, and try and get that to us for investigation.
I'm John Allspaw, co-founder of Adaptive Capacity Labs, where we help teams use their incidents to learn and improve. We bring research-driven methods and approaches to drive effective inciden...
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