On 08.03.2011 14:46, Philip Martin wrote:
stef...@apache.org writes:
Author: stefan2
Date: Mon Mar 7 22:57:04 2011
New Revision: 1079008
URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
Log:
Set FSFS cache default size to 16 MB. This is the same default as
for everybody else, namely the server processes. Thus, it should
be reasonable value on the same machines.
16MB may be "reasonable" for normal usage but it still has a significant
effect on the testsuite. The testsuite is an unusual access pattern, it
runs thousands of commands on small repositories. Using a 1MB cache I
can run the testsuite for ra_local/FSFS in 10m15s, with 16MB cache that
increases to 12m30s, a 20% increase. There is a similar increase when
testing ra_svn/FSFS using the default Linux svnserve (a threaded
svnserve has a shared cache so isn't affected).
The patch attached fixes the performance penalty
for "make check" by disabling membuffer caches
over ra_local by default. Since svn_ra_initialize is
being called early in main(), the setting can later
be overwritten by settings from e.g. a config file.
Could you verify that / whether this fixes your
performance issue?
svnserve and svnadmin both have a -M option, was there any discussion
about using a single letter option for this feature?
No.
This could be used
by the testuite to restrict the cache size, but for ra_local/FSFS
testing there is no way to restrict the svn client.
As already shown in a different thread, the memory
consumption should actually go down for any non-
trivial repository.
Should we add the -M option to the svn client?
Due to its limited applicability (FSFS via file:/// only),
I'm kind of -0 on adding that to the client. It is clearly
useful in certain cases but it may be hard to make
that clear to the average user.
It seems more likely to be a "on server" feature: run
svn (or others) from hook scripts. For max. speed,
admins could tweak their svn config file accordingly.
Should we make it configurable via .subversion/config instead or as well?
See above.
If svnadmin gets configured by .subversion/config should we remove the
command line option?
I'm +0 for the config file. For me, the CL is slightly
more convenient as it is easier to play with different
parameter values. The config file has the advantage
that each setting can be extensively documented /
commented.
-- Stefan^2.
Index: build.conf
===================================================================
--- build.conf (revision 1079481)
+++ build.conf (working copy)
@@ -260,7 +260,7 @@
description = Subversion Repository Access Library
type = lib
path = subversion/libsvn_ra
-libs = libsvn_delta libsvn_subr ra-libs apriconv apr
+libs = libsvn_delta libsvn_subr libsvn_fs_util ra-libs apriconv apr
# conditionally add more dependencies
add-deps = $(SVN_RA_LIB_DEPS)
add-install-deps = $(SVN_RA_LIB_INSTALL_DEPS)
Index: subversion/libsvn_ra/ra_loader.c
===================================================================
--- subversion/libsvn_ra/ra_loader.c (revision 1079481)
+++ subversion/libsvn_ra/ra_loader.c (working copy)
@@ -44,6 +44,7 @@
#include "svn_path.h"
#include "svn_dso.h"
#include "svn_config.h"
+#include "svn_fs.h"
#include "ra_loader.h"
#include "private/svn_ra_private.h"
@@ -249,6 +250,17 @@
svn_error_t *svn_ra_initialize(apr_pool_t *pool)
{
+ /* Per default, disable large expensive FS caching on the client side.
+ * We can still chose a different size for that cache later in the
+ * startup phase, e.g. after reading config files. If that does not
+ * happen until the first FSFS repository get opened, low initialization
+ * overhead caches will be used for the most time-critical structures.
+ *
+ * This is only relevant for FSFS over ra_local. */
+ svn_fs_cache_config_t settings = *svn_fs_get_cache_config();
+ settings.cache_size = 0;
+ svn_fs_set_cache_config(&settings);
+
return SVN_NO_ERROR;
}
