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.
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 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.
Hello everyone, Hope everyone is safe! A few months ago we posted an article sharing all the new articles and documentation that we, the AMER Jira Service Management team created. As mentioned ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events