Crucible failing to index even 1 SVN revision

[Craig McGuff]

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.

[Nick]

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 ?

Definitely consider:

1. increasing the JVM heap as suggested by Eddie Webb above
2. setting a start revision in the repo settings, to be one higher than the problem revision.
   1. this will mean earlier history will not be indexed, searchable, etc

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.

[EddieW]

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.