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

Re: Slow ISVNClient.getChangelists on Linux/NFS share

From: Thomas Singer <thomas.singer_at_syntevo.com>
Date: Thu, 19 Oct 2017 08:30:55 +0200

On 18.10.2017 19:56, Branko Čibej wrote:
> On 18.10.2017 13:31, Thomas Singer wrote:
>> Hi,
>>
>> When performing following steps on my old Linux test machine (with
>> slow hard disk):
>>
>> - have a SVN working copy at /home/user/test
>> - sudo apt install nfs-kernel-server
>> - add following line to /etc/exports:
>>   /home/user/test *(rw,sync,no_root_squash)
>> - start the NFS server:
>>   sudo systemctl start nfs-kernel-server.service
>> - mount the NFS share:
>>   sudo mount localhost:/home/user/test /home/user/test.nfs
>>
>> and then open /home/user/test.nfs in SmartSVN 9.2 (using SVN 1.9
>> JavaHL binaries), adding/removing a file is very slow. It boils down
>> to the call ISVNClient.getChangelists which takes ~8s on the NFS share
>> (/home/user/test.nfs). First, I thought, it would be caused by the
>> native-Java overhead calling the call-back ~11,000 times for my
>> working copy, but when using the working copy directly
>> (/home/user/test), the method just takes <1s though the ~11,000 times
>> call-back invocations are still there.
>>
>> My working copy has no local modifications, no untracked or ignored
>> files, no changelists.
>>
>> Is it expected that this method (ISVNClient.getChangelists) is so slow
>> on a NFS share even if there are no changelists?
>
> I don't know if it's "expected" but I bet that NFS is killing SQLite
> performance.
>
> https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg88989.html
>
> I'm not sure about the reason but the most likely answer, apart from
> slow data rate and latency when compared to a local filesystem (which,
> in your case on loopback, should not be an issue), is that the OS can't
> really use a cache for files on NFS since it has no way to know whether
> or not it's valid. With a lot of random-access reads and writes, that
> can be a HUGE slowdown, as you found.
>
>
> Also this:
> https://sqlite.org/faq.html#q5
>
> In other words, Subversion working copies on NFS are, and have always
> been, a bad idea; not only because of SQLite but also because
> Subversion's code itself relies on atomic renames, which NFS does not
> provide.
>
> -- Brane

What SVN command (on command line) I should test to get a similar result
as from ISVNClient.getChangelists? I've tried "git status" and it just
needs <1s on the NFS working copy.

--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://www.syntevo.com/blog
Received on 2017-10-19 08:31:31 CEST

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