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