Java heap size

The heap size of the Fisheye Java Virtual Machine is controlled by the FISHEYE_OPTS environment variable. The best heap size to use is dependent on a number of factors including:

• The source code management (SCM) system being used. Subversion scanning typically uses more memory than CVS, for example.
• The complexity of operations in the repository. Processing changesets which affect many files will use more memory.
• The amount of physical RAM in the system. If the Java heap is too large, it may induce swapping which will impact performance.

Fisheye will reserve a portion of the available heap for caching of database data. So in general, the more memory you can supply, the better.

For Subversion repositories, it is also possible to reduce Fisheye's memory footprint by reducing the Block Size parameter.

If you do run into 'out of memory' errors, see Fix out of Memory Errors. See also How Fisheye uses memory.

Note that when Fisheye is run as a Windows service using the Java Service Wrapper, environment variables are ignored – they must be configured in the wrapper config file instead. See Running Fisheye as a Windows service.

Default number of open files

If you have a large number of repositories, we recommend that you increase the default number of files that Fisheye is allowed to open. See this knowledge base article for more info: Subversion Indexer Paused with "Too many open files" Error.

Default number of memory maps

If you have a large number of repositories, we recommend that you increase the default number of maps that Fisheye is allowed to have. See this knowledge base article for more info: JVM crashes after Fisheye Crucible upgrade - Native memory allocation mmap.

Improve browse performance

For users with very large repositories, you may find the rendering of the Subversion tree slow. You can try disabling checking for empty folders by using the disable-dirtree-empty-checks option in your FISHEYE_ARGS environment variable.

Reduce overall server load

The incremental indexing process causes Fisheye to poll all repositories at the specified interval to check for new commits, even though there might not be any new information to index. If you have a large number of repositories (> 100), this can lead to:

• A time lag between a commit being made and it appearing in Fisheye.
• A high load on the Fisheye server, and on the SCM.

Configuring commit hooks will allow you to set up your SCM so that indexing of a repository is triggered by a commit to the repository itself. This means that Fisheye only runs the indexing process when necessary, and allows automatic polling to be disabled. Commits will appear sooner in Fisheye, and the server load will be reduced.

Improving initial scan performance

Background information

When you add a repository, Fisheye needs to perform a once-off scan through the repository to build up its initial index and cache. This scan can take some time. Until this scan is complete, you may find that some data is not displayed. As a guide, Fisheye should be able to process about 100KB-200KB per second on an averaged-size PC. If Fisheye is accessing the repository over the network (e.g. over a NFS mount), then you should expect the initial scan to take longer.

General improvements

You can increase the speed of your scans using the following options:

• If your repository is non-local, set up a local repository mirror on the Fisheye server. This will provide a major speed boost for anyone scanning a repository across a network.
• Exclude unused file types, unused directories and specific large files from Fisheye.

Improve update performance during initial scan

One option is break large repositories into multiple smaller repositories. While this technique will not improve the overall initial scan time, it allows for all fully scanned repositories to be updated while the initial scan is still being performed on those remaining.

In Fisheye 1.3.4 and later, the initial and incremental scans happen in separate, single threads. So, splitting the repositories will allow incremental scans to run concurrently alongside the initial scans. You may also wish to split projects into separate repositories, since permissions in Fisheye are applied on a per-repository basis.

Improving initial scan performance for an SVN repository

The http/s protocol has the slowest performance during the initial scan. The svn protocol (svn://) is faster and the file protocol (file:///) is the fastest.

Therefore if you find your initial scan takes an extended amount of time (more than a day or two), you should consider switching over from the http/s protocol to the svn or file protocol to define the location of your SVN repository. (Use svnsync to mirror the repository onto the fisheye server, so that you can access it with the file protocol.)

E.g. Switch from 
https://example.com/svn/project/
to
svn://example.com/svn/project/
or
file:///home/user/some/location/svn/project

In order for SVN protocol to work you need to have set up an svnserve based server.

More information on how to troubleshoot SVN indexing related issues can be found here.