[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Weirdness

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-06-13 21:49:16 CEST

C. Michael Pilato wrote:
> Artem Egorkine wrote:
>
>>I have a simple test case: I add to my repository a thousand nested
>>directories and try to
>>check them in
>>
>>0
>>0/0
>>0/0/0
>>0/0/0/0
>>...
>>
>>The back-end is BDB over DAV. BDB is 4.3.29, Apache is 2.2.2, SVN is
>>1.3.1 (or trunk)
>>
>>The check-in is successful, but on cleanup the apache process starts
>>to grow in memory while being in the "Closing connection" state.
>>
>>Similarly, if using ra_local, the SVN process starts to grow in memory
>>and check-in never finishes.
>
>
> I tried to reproduce this with 1.4.0-rc1. The 'svn add' step was a memory
> hog indeed, growing up to 250M of usage, but succeeding. The commit step,
> however, was a quick jump to 55M (likely entries caching, working copy
> locking, etc.), and held steady there for the duration of the commit. But
> during post-commit deltification, it just seemed to spin. I attached to the
> process, and found 300 stack levels of recursion in deltify_mutable(). I
> continued, and interrupted a little while later to find 98 recursion levels
> of apr_pool_walk_tree() below 353 recursions of deltify_mutable()!!
>
> Clearly, there's an algorithm that's not scaling so well.

Ouch. That really didn't pan out well for me. I walked away from my
computer to work on a different one, and when I came back, it was basically
unresponsive (resource-strapped). Guess I crossed the stack depth line of
no return. Anyway, a reboot later, I can confirm that my commit actually
happened. Post-commit deltification? I kinda doubt that finished...

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Tue Jun 13 21:50:04 2006

This is an archived mail posted to the Subversion Dev mailing list.