Edgewall Software
Modify

Opened 15 years ago

Closed 15 years ago

#5213 closed enhancement (fixed)

Changset view is slow when using sub repostiory path

Reported by: trac@… Owned by: Christian Boos
Priority: high Milestone: 0.11
Component: version control/changeset view Version: 0.10.4
Severity: critical Keywords: svn scoped
Cc: sam@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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.

Attachments (0)

Change History (10)

comment:1 by Emmanuel Blot, 15 years ago

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.

comment:2 by trac@…, 15 years ago

Ups, sorry forgot that.

our version of trac is:

Trac 0.10.3.1

Dominik

comment:3 by anonymous, 15 years ago

Version: 0.10.3.1

Another thing I forgot to mention:

DB Backend is Postgres 8.1.3.

comment:4 by Christian van der Leeden <fanta@…>, 15 years ago

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

comment:5 by Christian van der Leeden <fanta@…>, 15 years ago

Version: 0.10.3.10.10.4

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…

comment:6 by Christian Boos, 15 years ago

Keywords: svn scoped added
Milestone: 0.10.5

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/

comment:7 by sam@…, 15 years ago

Cc: sam@… added

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.

in reply to:  5 comment:8 by Christian Boos, 15 years ago

Milestone: 0.10.50.11
Priority: normalhigh

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.

comment:9 by Christian Boos, 15 years ago

Severity: normalcritical
Status: newassigned

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.

in reply to:  9 comment:10 by Christian Boos, 15 years ago

Resolution: fixed
Status: assignedclosed

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.