[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: Branko Čibej <brane_at_apache.org>
Date: Wed, 18 Oct 2017 19:56:33 +0200

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
Received on 2017-10-18 19:56:41 CEST

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.