On Tue, May 15, 2012 at 7:55 PM, Moe, Mark wrote:
>> I rewrote some parts of the commit processing on trunk last week, which
>> should have a positive effect on the use cases reported in this thread.
>
>> Is it possible for somebody to see what the performance difference on NFS
>> is?
>
> Does thi
> I rewrote some parts of the commit processing on trunk last week, which
> should have a positive effect on the use cases reported in this thread.
> Is it possible for somebody to see what the performance difference on NFS
> is?
Does this include Phillip's patch
(http://subversion.tigris.org/is
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: vrijdag 4 mei 2012 21:15
> To: Moe, Mark
> Cc: Philip Martin; dev@subversion.apache.org; Braun, Eric
> Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working
> copies
>
>
> Well... your interest has already been noted :-) Maybe you're asking
> how you can help get the bug fixed? Volunteering, of course (as we all
> are).
...
> If you're not talking about digging into the code yourself, then... I
> dunno. Maybe one of the Subversion vendors is willing to do spot f
> Cc: Daniel Shahaf; dev@subversion.apache.org; Braun, Eric
> Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working
> copies
>
> "Moe, Mark" writes:
>
>> Can this patch be marked as an issue or enhancement idea?
>
> I've raised http://subv
To: Moe, Mark
Cc: Daniel Shahaf; dev@subversion.apache.org; Braun, Eric
Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies
"Moe, Mark" writes:
> Can this patch be marked as an issue or enhancement idea?
I've raised http://subversion.tigris.org/issu
"Moe, Mark" writes:
> Can this patch be marked as an issue or enhancement idea?
I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4176
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
ay 01, 2012 2:34 PM
To: Daniel Shahaf
Cc: Moe, Mark; dev@subversion.apache.org; Braun, Eric
Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Philip Martin writes:
> Daniel Shahaf writes:
>
>> What patch are you talking about? I don't recall seeing a
Here are some quick benchmarks with our environment of the improvement the
patch provides.
1.7.4 1.7.4-patch
svn co 8m24s 4m8s
svn st 13.3s 3.2s
svn ci 1m31s 4.1s
svn rm * 1.85s 6.3s
svn revert 46.6s 4.0s
Seems to me that the default behavior should be to ena
Philip Martin writes:
> Daniel Shahaf writes:
>
>> What patch are you talking about? I don't recall seeing a patch on list
>
> http://svn.haxx.se/dev/archive-2012-02/0413.shtml
>
> It executes the SQLite statement "pragma locking_mode = exclusive" after
> opening wc.db.
We can't simply commit
> I don't really know how to proceed. The performance gains are huge
> on NFS and it's hard to see any other way to fix the 1.7 regression.
> We could sacrifice concurrency for performance and enable it all the
> time, essentially deciding that this is the way that WCNG will use
> SQLite.
I don't
Daniel Shahaf writes:
> What patch are you talking about? I don't recall seeing a patch on list
http://svn.haxx.se/dev/archive-2012-02/0413.shtml
It executes the SQLite statement "pragma locking_mode = exclusive" after
opening wc.db.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN
Moe, Mark wrote on Tue, May 01, 2012 at 10:33:36 -0500:
> Yes, I tried it and it was very effective! See below:
>
> 1.6.17 1.7.4 1.7.4-patched
> NFS benchmark*1534s 4074s 572s
> Local benchmark* 365s162s
Behalf Of Philip Martin
Sent: Tuesday, May 01, 2012 3:19 AM
To: Moe, Mark
Cc: dev@subversion.apache.org
Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Mark Moe writes:
> This is a big deal for us too. Will there be a configuration setting in an
> official svn
"Moe, Mark" writes:
> Yes, I tried it and it was very effective! See below:
>
> 1.6.17 1.7.4 1.7.4-patched
> NFS benchmark*1534s 4074s 572s
> Local benchmark* 365s162s118s
> NFS svn co29
Mark Moe writes:
> This is a big deal for us too. Will there be a configuration setting in an
> official svn 1.7.x version that we can use to enable the exclusive lock mode
> for SQLite? (assuming that is a valid fix for this issue)
Are you able to try a patch and tell us how effective it is?
, the same operation with the same working copy takes 2s
in subversion 1.6.17 vs 1m11s in 1.7.2. This is a pretty big deal for us.
--
View this message in context:
http://old.nabble.com/svn-ci-performance-issue-with-1.7.x-and-nfs-mounted-working-copies-tp32976250p33763319.html
Sent from the
-ColSprings,ex1); dev@subversion.apache.org
Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies
[Philip Martin]
> That will be because commit does one or more SQLite transactions
> per-node, while status has been optimised to do fewer per-directory
> transacti
[Philip Martin]
> That will be because commit does one or more SQLite transactions
> per-node, while status has been optimised to do fewer per-directory
> transactions. The number of SQLite transactions is what dominates
> Subversion working copy performance on network disks. By running
> commit
writes:
> If I run "svn ci" from the root of my working copy it takes 1m11s to
> complete. However if I instead run
>
> cd
> svn st
> cd subdir
> svn ci
> cd
> svn up
>
> That whole set of commands takes 16s to run. The actual change I am
> committing is adding or deleting a single line of a
I originally sent this to users@ but didn't get any response. Trying dev@.
I'm really starting to get some pushback from our engineers wanting to go back
to 1.6.x because of pretty severe performance slowdowns.
In addition to slow "svn rm" commands we are seeing some pretty severe
slowdowns f
21 matches
Mail list logo
