nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Fisheye huge I\O load and slow content indexing

vadim vadim2

Hi

INVENTORY:

I have fisheye 2.6.2 on centos 5.6 x32 with 3Gb of RAM and 4 cpu cores.

My fishyey opts and arg:

/usr/bin/java -Xms2048m -Xmx2048m -XX:MaxPermSize=256m -Xss512k -XX:MaxNewSize=128m -Dfisheye.library.path= -Dfisheye.inst=/srv/fecru262 -Djava.awt.headless=true -Djava.endorsed.dirs=/srv/fecru262/lib/endorsed -jar /srv/fecru262/fisheyeboot.jar start --Xdisable-dirtree-empty-checks --Xdisable-content-indexing

Repository resides on fisheye server file:///srv/svn-mirror/mirror-rps

iostat -xmn 1 shows huge I\O load generated by fisheye, ~700 writte operation per second. This load persists about a week on INTEL 320 SSD 80GB and content indexing of repository is not finished.

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sdd 0.00 1.00 52.00 765.00 0.42 8.00 21.12 0.16 0.19 0.14 11.10

PROBLEM

1.

iostat -xmn 1 shows huge I\O load generated by fisheye, ~700 writte operation per second. This load persists about a week on INTEL 320 SSD 80GB and content indexing of repository is not finished.

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sdd 0.00 1.00 52.00 765.00 0.42 8.00 21.12 0.16 0.19 0.14 11.10

2. Repository browsing is very slow

I have read all Atlassian documentation abou it and can`t resove issue. Please help me resolve this perfomance issue.

Accepted answers

All comments

Nic Brough -Adaptavist-

Hmm, some quick starter questions

How big is your repository?
How is it structured? I mean, is it lots of little repos, or just one big monolithic one? If it is one huge one, have you told Fisheye to scan the whole lot, or just bits of it?
If it's a large single repo, how many revisions are you on?

vadim vadim2

1. 400MB

2. One big repo with many subdirectories. I told to scan it all (no option, i must did such)

3. 8115 revisions

Nic Brough -Adaptavist-

Ok, that rules out the scalability problem - Fisheye can't cope with a large repo - my current client is on around 60Gb and 500,000 revisions, and Fisheye stopped coping around 250,000 revisions. But 8000 in a 400Mb repo is fine.

vadim vadim2

Do not know which way to dig. Just out of ideas

Bernard O'Flynn

I would open a request with Atlassian support. We had a similar issue and it was down to the way the trunk, branches and tags were setup in FE, i.e. the reg ex, etc.

We ended up not indexing tags as we were never going to use it for reviews. And we were never going to look at tags in FE either. That took our scan from over 2 weeks and still uncompleted down to a day and a half all done.

vadim vadim2

What atlassian suport recomend you to do? Do you have any patches or issue references about this problem?

mwatson

A normal trunk/tags/branches repo with 8K commits and 400MB should take about 2 hours at most - factors that can make it slower are lots of tags and branches, lots of complex tags and branches, svn files being on NFS or other network file system or an incorrect symbolic setup (i.e. not using a standard trunk/tags/branches and not changing FishEyes config to cope).

I recommend going to https://support.atlassian.com and opening a suport request.