Fishseye stuck on indexing (GC overhead limit exceeded)

[Deleted user]

Hello, Im running Fisheye 4.5.1 (Centos7, 4GB RAM) w trial license 

Im having several issues trying to index several large SVN repos

#1 I am getting the following error when restarting Fisheye,

2018-03-19 11:08:37,958 WARN - Problem processing revisions from repository OPS (OPS) due to class com.cenqua.fisheye.rep.RepositoryClientException - java.lang.OutOfMemoryError: GC overhead limit exceeded
com.cenqua.fisheye.rep.RepositoryClientException: java.lang.OutOfMemoryError: GC overhead limit exceeded

I set the Java params like this, 

export FISHEYE_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=256m -Xss512k"

memory looks ok, 

[root@njofisheye01 /opt/atlassian/fisheye]# free -m
total      used free shared buff/cache available
Mem: 3791   1412   672 15 1706 2057
Swap: 2047   427    1620

Not sure why its getting garb collection errors,

also indexing of my Repo just hangs at a certain point, never moves, forward (Im guessing its due to GC errors), even after multiple restarts. 

Can anyone suggest possible workarounds. Thanks. 

[daniele_carcasole · Accepted solution]

Hi,

The error:

java.lang.OutOfMemoryError: GC overhead limit exceeded

indicates that the JVM took too long to free up memory during its garbage collection process.

This kind of OutOfMemoryError can be caused if your java process is starting to use swapped memory for its heap.

You can read more on this at Fix Out of Memory errors, the page also suggests some parameters to add to your JVM options to help you investigate in case of OOM issues by generating HeapDump on OOM errors and a GC log during Fisheye/Crucible execution.

also indexing of my Repo just hangs at a certain point, never moves, forward (Im guessing its due to GC errors), even after multiple restarts. 

You are correct, when an error happens while indexing a changeset in repository, Fisheye stops the index. The fact the same revision always fails is preventing the index to proceed further.

In your case the problematic revision seems to be 12383 (just based on your screenshot).

In case you want to dig further into the issue you can:

Find out the revision that is causing the issue

• Enable DEBUG logging at Administration > Server > Debug Logging
• Wait for the issue to happen again
• Identify in the logs the svn commands being executed by Fisheye when the issue happened
• Execute the command using the jsvn command present in <Fisheye installation directory>/bin/lib/svn/jsvn and redirecting the output to a file
• Check the isze of the command outpur to get an idea of the HEAP needed to index that changeset

Add more RAM

In case you are still evaluating the application one simple test to try proceeding further would be to add more RAM to the server and retry the index. This should give more room for the server to allocate memory for processes when needed and will not slow down the instance by using the SWAP.

Hope this helps

Daniele

[Deleted user]

Daniele, thanks for the detailed reply, 

I added another 8G of RAM to the VM that was running fisheye and that seems to do the trick. Thanks.