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

Re: mod_dav/mod_dav_svn PROPFINDS.

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2002-07-01 20:49:49 CEST

On Sun, Jun 30, 2002 at 01:03:22AM -0400, Kevin Pilch-Bisson wrote:
> Hey,
> Trying to help someone on IRC today, I imported the linux kernel source into a
> repository. I then tried to check it out over dav and had problems. After
> watching for a while, I noticed that whenever the checkout started a new
> directory it would stop for quite a while, and the httpd memory usage would
> grow. I soon found out that my svn client would time out before getting a
> PROPFIND request back for the include/linux directory of the kernel sources.
> The reason for this is that my machine starts thrashing, because the httpd
> process trying to do the propfind grows huge (680MB before I killed it).(Note
> by contrast that opening the directory in w3m took about 2 seconds, and I
> didn't notice httpd's memory usage.

BTW, I *think* it is related to the fact that the dav_svn_do_walk
function isn't creating a subpool.

I'm specifically looking at subversion/mod_dav_svn.c:1963:

  /* fetch this collection's children */
  /* ### shall we worry about filling params->pool? */
  serr = svn_fs_dir_entries(&children, ctx->info.root.root,
                            ctx->info.repos_path, params->pool);

If we had svn blame, we could figure out who added the ### comment
and I believe whomever said that is right.

Before calling this function, I think a subpool needs to be
created and then delete it as we exit this function. This will mean
that the pool will only grow to the depth of the recursive tree, but
no more than that rather than the unbounded growth we have now.

Thanks to Sander who pointed this out to me. I've been trying
(unsuccessfully) to talk to him wrt to this after he pointed it
out, so I'll post here in the hopes someone will jump on this.

I'm not sure I have the time to play with this, but I'm willing to
guess that this is the problem. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 1 20:50:15 2002

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.