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

Re: svn commit: r982355 - /subversion/branches/performance/subversion/svnserve/main.c

From: Blair Zajac <blair_at_orcaware.com>
Date: Tue, 9 Nov 2010 19:42:25 -0800

On Aug 4, 2010, at 11:43 AM, stefan2_at_apache.org wrote:

> Author: stefan2
> Date: Wed Aug 4 18:43:29 2010
> New Revision: 982355
>
> URL: http://svn.apache.org/viewvc?rev=982355&view=rev
> Log:
> Fix an issue with fulltext caching already present in production SVN:
> APR pools often won't reuse memory fragments if they are larger
> than 80kB. Using string buffers while reconstructing fulltexts does
> exactly The Bad Thing: request large buffers of various sizes that
> APR pools will often not reuse due to their differing and often just
> a tad bit too small size.
>
> Use an allocator to limit the amount of unused memory fragments
> held by the root pools.

Some questions on this:

Do we not need this in mod_dav_svn because we assume that Apache exits child processes after N HTTP requests?

What about for Windows Apache servers, where they only have a threading server model, should this be enabled? Or would it be too hard to have only svn pools use this

We have a custom, multithreaded Ice Subversion server that can run for months at a time. It only serves full texts to clients and it doesn't expose any diff methods. I've seen slow growth over time, but we also have an internal LRU cache for svn_repos_t, svn_fs_t, svn_fs_root_t, so it's hard to tell what's allocating memory. I guess we should do that in this process just to be safe?

It looks like every command line tool we have does this:

./subversion/svnadmin/main.c:1578: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
./subversion/svndumpfilter/main.c:1277: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
./subversion/svnlook/main.c:2214: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
./subversion/svn/main.c:1260: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
./subversion/svnserve/main.c:806: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
./subversion/svnsync/main.c:1808: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
./subversion/svnversion/main.c:149: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
./tools/client-side/svnmucc/svnmucc.c:88: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
./tools/dev/svnraisetreeconflict/main.c:341: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);
./tools/server-side/svn-rep-sharing-stats.c:451: apr_allocator_max_free_set(allocator, SVN_ALLOCATOR_RECOMMENDED_MAX_FREE);

Any reason we just don't make this part of svn_cmdline_init()?

Blair
Received on 2010-11-10 04:49:47 CET

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.