You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Artem Egorkine <ar...@gmail.com> on 2006/06/13 08:45:33 UTC
Weirdness
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.
Any ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weirdness
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/13/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 6/13/06, Artem Egorkine <ar...@gmail.com> wrote:
> > My appologies, the subject should have been "Problems checkin-in 1000
> > nested directories with BDB".
> >
> > Just to one thing:
> >
> > Using FSFS backend I don't even that far - it fails mid-way adding
> > directories, but that's a separate issue...
>
> There's actually an issue about that. FSFS has a maximum path length
> in it, if you nest too deeply you hit it eventually. I've got a patch
> lying around that fixes it (in the sense that you at least get a
> somewhat sane error), but haven't gotten around to committing it
> yet...
Ahh, found the fsfs bug:
http://subversion.tigris.org/issues/show_bug.cgi?id=2508
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weirdness
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/13/06, Artem Egorkine <ar...@gmail.com> wrote:
> My appologies, the subject should have been "Problems checkin-in 1000
> nested directories with BDB".
>
> Just to one thing:
>
> Using FSFS backend I don't even that far - it fails mid-way adding
> directories, but that's a separate issue...
There's actually an issue about that. FSFS has a maximum path length
in it, if you nest too deeply you hit it eventually. I've got a patch
lying around that fixes it (in the sense that you at least get a
somewhat sane error), but haven't gotten around to committing it
yet...
The BDB side certainly sounds like a bug, and one should probably be
filed for it.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weirdness
Posted by Artem Egorkine <ar...@gmail.com>.
My appologies, the subject should have been "Problems checkin-in 1000
nested directories with BDB".
Just to one thing:
Using FSFS backend I don't even that far - it fails mid-way adding
directories, but that's a separate issue...
BR,
Artem Egorkine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weirdness
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/14/06, C. Michael Pilato <cm...@collab.net> wrote:
> Garrett Rooney wrote:
> > On 6/13/06, C. Michael Pilato <cm...@collab.net> wrote:
> >
> >> 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...
> >
> >
> > Hmm. I wonder if it's stack depth, or just memory usage. If it's
> > stack depth, we can avoid that by simply rewriting the algorithm to
> > not be recursive (using an explicit stack rather than the C call
> > stack, etc), the problem is if we're just running out of memory
> > because each level of recursion uses an APR pool the fix is far less
> > straitforward...
> >
> > FWIW, I suspect it's not an easy fix. If you'd run out of C stack
> > you'd probably have crashed, as opposed to just slowing to a crawl...
>
> Actually, I wonder if we couldn't simply switch from a
> crawl-the-tree-to-find-modified-things (recursive) approach to an
> ask-the-changes-file-what-changed (iterative) approach?
Sounds worth looking into.
Note that I've filed issue 2570 to track this problem.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weirdness
Posted by "C. Michael Pilato" <cm...@collab.net>.
Garrett Rooney wrote:
> On 6/13/06, C. Michael Pilato <cm...@collab.net> wrote:
>
>> 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...
>
>
> Hmm. I wonder if it's stack depth, or just memory usage. If it's
> stack depth, we can avoid that by simply rewriting the algorithm to
> not be recursive (using an explicit stack rather than the C call
> stack, etc), the problem is if we're just running out of memory
> because each level of recursion uses an APR pool the fix is far less
> straitforward...
>
> FWIW, I suspect it's not an easy fix. If you'd run out of C stack
> you'd probably have crashed, as opposed to just slowing to a crawl...
Actually, I wonder if we couldn't simply switch from a
crawl-the-tree-to-find-modified-things (recursive) approach to an
ask-the-changes-file-what-changed (iterative) approach?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Weirdness
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/13/06, C. Michael Pilato <cm...@collab.net> wrote:
> 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...
Hmm. I wonder if it's stack depth, or just memory usage. If it's
stack depth, we can avoid that by simply rewriting the algorithm to
not be recursive (using an explicit stack rather than the C call
stack, etc), the problem is if we're just running out of memory
because each level of recursion uses an APR pool the fix is far less
straitforward...
FWIW, I suspect it's not an easy fix. If you'd run out of C stack
you'd probably have crashed, as opposed to just slowing to a crawl...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weirdness
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Weirdness
Posted by "C. Michael Pilato" <cm...@collab.net>.
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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand