Changset view is slow when using sub repostiory path

[trac@…]

We are evaluating Trac and come across the following problem. If we use the whole subversion repository in a trac project the changeset view works fast. If we use a subpath of the repository for a trac project viewing changesets gets very slow. Also with see that the memory usage of tracd gets very large in this usage case (> 300MB).

We use db4 as subversion backend (v 1.4.2) and running trac standalone with tracd.

[Emmanuel Blot]

We use db4 as subversion backend (v 1.4.2) and running trac standalone with tracd.

While I don't think it is related to the issue, using BDB as a SVN backend is not recommended with Trac.

Please specify which version of Trac you are using.

[trac@…]

Ups, sorry forgot that.

our version of trac is:

Trac 0.10.3.1

Dominik

[anonymous]

Another thing I forgot to mention:

DB Backend is Postgres 8.1.3.

[Christian van der Leeden <fanta@…>]

I'd like to give more debug information for this ticket.

Could you give me some points on how to see what svn activity trac is doing? Any logging that I could use to see what svn commands trac is using?

Christian

[Christian van der Leeden <fanta@…>]

The oldest revision is calculated each time by stepping through all the revisions of the repository starting at revision 0. We have 14800 commits, so the calcuation of this call takes around 12 seconds. Memory usage is also very high. We've just recently restructed our repository so the URL the call is looking for ist at one of the latest revisions.

Commenting out the self.next_rev and leaving it at 1 solved our problem… why is this needed anyway?

    def get_oldest_rev(self):
        if self.oldest is None:
            self.oldest = 1
            self.log.debug('repos: get_oldest_rev')

            # this call steps through each revision starting at revision 0
            if self.scope != '/':
                self.oldest = self.next_rev(0, find_initial_rev=True)

            self.log.debug('repos: get_oldest_rev 2')
        return self.oldest

P.S. We upgraded to 10.4.0…

[Christian Boos]

Support for scoped path will be much improved in 0.12.

But I'll have a look if we could improve things for 0.10-stable and 0.11 by improving the implementation or usage of get_oldest_rev/

[sam@…]

I can confirm that this issue affects 0.11, and that the hack (commenting out the "if self.scope" line and the line below it) appears to resolve the problem.

It would be good to know what we risk breaking by having self.oldest set == 1.

[Christian Boos]

Replying to Christian van der Leeden <fanta@samira.de>:

… Memory usage is also very high. …

Hm, I wonder if that's not related to the recent increase of issue reported for high memory usage.

Setting to milestone:0.11 to make that issue more visible, but the fix should still be backported to milestone:0.10.5.

[Christian Boos]

I confirm that the memory usage is indeed catastrophic in this situation.

Requesting a hundred changesets from /sandbox in a t.e.o mirror, tracd's memory usage stabilized at 155 Mbytes. Doing the same when the scope was set to '/sandbox', it reached 1.2 Gbytes after only 50 changesets and didn't feel like it was going to stop growing…

Commenting out the next_rev line does indeed the trick, as the memory usage more or less stabilizes again near 170 Mbytes, but I'd like to understand the reason why this leaks memory in that proportion.

The negative impact of that change would be minimal, if any: the justification for this was only "correctness", IIRC.

[Christian Boos]

Fixed by [6328].

The negative impact of that change would be minimal, if any: the justification for this was only "correctness", IIRC.

Well, no, it was actually used during the resync, as explained in the changeset message.