Since migrating to MySQL made a noticeable difference for some repositories, consider tuning the database for further improvements. Changing some my.cnf
values from the defaults can make a huge difference. See InnoDB Performance Optimization Basics for more information. Also check for slow queries by enabling the slow query log and add indexes where appropriate.
My next guess would be network speed: is your Crucible instance on the same wired local network as your SVN repositories? You might also try giving Crucible a trial run on the same machine as your primary repository if possible to eliminate network latency as the culprit.
And I know it might be difficult depending on your work environment, but running Crucible in a VM probably isn't helping things; Atlassian makes a note of this on their very brief Best Practices for Crucible Configuration page. I'm sure you've already come across it, but I'll also mention the Tuning FishEye page for other readers.
I also have performance issues for large projects, but attribute a lot of the slowness to Crucible's heavy web interface. This is especially true after clicking around for a bit (previously viewed pages in a review remain in the browser window, even when hidden from sight). Our developers have noticed a slight speed increase by switching to Google Chrome. Also check out the Atlassian IDE Connector if a compatible plugin exists for your development environment. The Eclipse IDE Connector had issues of its own the last time I used it (many months ago), but it could at least handle large file sets without hanging up.
Depending on your company's development practices, you could stop scanning a large number of code branches (assuming many of them are no longer active), and disable repositories for completed/dead projects until they're needed. My company utilizes very small teams on a large number of projects, so most of the time we work primarily on trunk
, making branches the exception; we therefore explicitly add branches to scan instead of including all branches by default. Also make sure you're not accidentally scanning tags.
How is your CPU usage on the Crucible box? If you're using SVN behind Apache HTTPD, examine how many connections are consumed by Crucible during a big repository scan. Aside from that, I'm not sure what else you could look at (maybe disk speed? Repository scan frequency?), but hopefully the above tips will help a bit.
You can set this in your Wrapper.conf file. Here's my config file and this is working great for me, I'm using this with Fisheye 2.6.3 running on Windows Server 2008 R2. This file is mostly identical to the sample/default configuration, with a few important additions that I'll comment on at the end.
#********************************************************************
# Wrapper Properties
#********************************************************************
# Working Directory
wrapper.working.dir=../../
# Java Application
wrapper.java.command=C:\Program Files\Java\jdk1.6.0_25\bin\java.exe
# Java Main class. This class must implement the WrapperListener interface
# or guarantee that the WrapperManager class is initialized. Helper
# classes are provided to do this for you. See the Integration section
# of the documentation for details.
wrapper.java.mainclass=com.cenqua.fisheye.FisheyeServiceWrapper
# Java Classpath (include wrapper.jar) Add class path elements as
# needed starting from 1 (add lib FIRST so that log4j config gets loaded first)
wrapper.java.classpath.1=./fisheyeboot.jar
wrapper.java.classpath.2=wrapper/lib/*.jar
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=wrapper/lib
wrapper.java.library.path.2=lib/native/linux-i386
wrapper.java.library.path.3=lib/native/osx-ppc
wrapper.java.library.path.4=lib/native/solaris-sparc
wrapper.java.library.path.5=lib/native/win32-x86
# Java Additional Parameters
wrapper.java.additional.1=-server
wrapper.java.additional.2=-showversion
wrapper.java.additional.3=-Djava.awt.headless=true
# JDK 1.5 Additional Parameters for jmx
wrapper.java.additional.4=-Dcom.sun.management.jmxremote
wrapper.java.additional.5=-Dcom.sun.management.jmxremote.port=4242
wrapper.java.additional.6=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.7=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.8=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.9=-Dcom.sun.management.jmxremote.password.file=./wrapper/jmxremote.password
wrapper.java.additional.10=-Dwrapper.mbean.name="wrapper:type=Java Service Wrapper Control"
wrapper.java.additional.11=-Dfisheye.inst="C:\Atlassian\fecru-2.6.3\bin\.."
wrapper.java.additional.12=-XX:MaxPermSize=256m
wrapper.java.additional.13=-Xrs
wrapper.java.additional.14=-Dfile.encoding=UTF-8
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=64
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024
# Application parameters. Add parameters as needed starting from 1
# The first application parameter is the name of the class whose main
# method is to be called when the application is launched. The class
# name is followed by the number of parameters to be passed to its main
# method. Then comes the actual parameters.
wrapper.app.parameter.1=com.cenqua.fisheye.FishEyeCtl
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start
# The start parameters are followed by the name of the class whose main
# method is to be called to stop the application. The stop class name
# is followed by a flag which controls whether or not the Wrapper should
# wait for all non daemon threads to complete before exiting the JVM.
# The flag is followed by the number of parameters to be passed to the
# stop class's main method. Finally comes the actual parameters.
wrapper.app.parameter.4=com.cenqua.fisheye.FishEyeCtl
wrapper.app.parameter.5=true
wrapper.app.parameter.6=1
wrapper.app.parameter.7=stop
#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Format of output for the console. (See docs for formats)
wrapper.console.format=M
# Log Level for console output. (See docs for log levels)
wrapper.console.loglevel=INFO
# Log file to use for wrapper output logging.
wrapper.logfile=var/log/wrapper.log
# Format of output for the log file. (See docs for formats)
wrapper.logfile.format=LPTM
# Log Level for log file output. (See docs for log levels)
wrapper.logfile.loglevel=INFO
# Maximum size that the log file will be allowed to grow to before
# the log is rolled. Size is specified in bytes. The default value
# of 0, disables log rolling. May abbreviate with the 'k' (kb) or
# 'm' (mb) suffix. For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=50m
# Maximum number of rolled log files which will be allowed before old
# files are deleted. The default value of 0 implies no limit.
wrapper.logfile.maxfiles=10
# Log Level for sys/event log output. (See docs for log levels)
wrapper.syslog.loglevel=NONE
#********************************************************************
# Wrapper Windows Properties
#********************************************************************
# Title to use when running as a console
wrapper.console.title=Fisheye
#********************************************************************
# Wrapper Windows NT/2000/XP Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
# using this configuration file has been installed as a service.
# Please uninstall the service before modifying this section. The
# service can then be reinstalled.
# Name of the service
wrapper.ntservice.name=Fisheye
# Display name of the service
wrapper.ntservice.displayname=Fisheye
# Description of the service
wrapper.ntservice.description=Fisheye
# Service dependencies. Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=
# Mode in which the service is installed. AUTO_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START
# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false
Noteworthy Lines
wrapper.java.command=C:\Program Files\Java\jdk1.6.0_25\bin\java.exe
Full path to the JDK 'hotspot' server executable. Note, download the full JDK, not just the JRE.
wrapper.java.additional.11=-Dfisheye.inst="C:\Atlassian\fecru-2.6.3\bin.."
wrapper.java.additional.12=-XX:MaxPermSize=256m
wrapper.java.additional.13=-Xrs
wrapper.java.additional.14=-Dfile.encoding=UTF-8
None of the above are shown in the Atlassian documentation, I have added these over time through trial and error. When FeCru is first started under the service wrapper, it may stop with an out of memory error, the 'MaxPermSize' line fixes that.
I've also found it is necessary to specify FISHEYE_INST as shown above. I have no idea why the path is specified with /..
on the end, it was like that in the example I found. Some cooky linux ritual, no doubt. The other lines, I can't remember what they were for, but I added them for some reason or another and didn't document why. Nobody's perfect ;-)
wrapper.java.initmemory=64
wrapper.java.maxmemory=1024
Heap memory allocations increased from the defaults - I index some fairly meaty repositories and I could afford the extra resources - you may get away with the default smaller allocations.
Best Answer
As this question popped up again and the answers are now outdated since the switch to systemd by the major distributions I'll add my systemd service definition for JIRA:
/etc/systemd/system/jira.service
/etc/sysconfig/jira
Replace
/path/to/jira
with your application directory.For the other Atlassian tools it's basically the same, just the startup scripts and the PID file location differ slightly:
Confluence
$appdir/bin/startup.sh
$appdir/bin/shutdown.sh
$appdir/work/catalina.pid
FishEye
$appdir/bin/start.sh
$appdir/bin/stop.sh
Bamboo
$appdir/bin/start-bamboo.sh
$appdir/bin/stop-bamboo.sh
Crowd
$appdir/bin/startup.sh
$appdir/bin/shutdown.sh
$appdir/apache-tomcat/work/catalina.pid
FishEye doesn't have support for a PID file yet, so currently it is necessary to use the workaround from that issue and add this line to
fisheyectl.sh
after thenohop
command:For Bamboo the PID file has to be explicitly defined via the
CATALINA_PID
variable (see$appdir/bin/catalina.sh
). I haven't tested it yet, but it should be possible to set this variable in theEnvironmentFile
file.After the service definitions are created: