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

Re: Extremely slow merges

From: <Stefan.Fuhrmann_at_etas.de>
Date: 2004-12-29 17:36:23 CET

kfogel@collab.net writes:

> It would be helpful if you could first narrow down whether the problem
> originates in the client, or server, or both. First downgrade one
> side back to whatever SVN you were using before; then revert and
> downgrade the other side; then downgrade both. At each stage, test a
> merge (the exact same one each time), and see if its speed changes
> drastically. This way we can narrow down the regression.

Accidentially, I performed a pretty huge merge operation
(2000+ files / folder changes) today. In fact, it is still running ;)

My config:

* Server: SVN 1.1.1 on W2k, 3GHz XEON, 2GB RAM, SCSI RAID, NTFS
* Client: SVN 1.1.1 on XPpro, 2.4GHz Opteron, 2GB RAM, IDE Disk, NTFS
* HTTP access via CL client over 100MBit Ethernet LAN

* BDB4.2 repository, 1.52 GB, 12000 revs
* trunk is 20k+ user files (mostly source code) in 1k+ user folders
* wc size is about 100MB

My observations:

* network load is low:
  50 .. 100 kBIT / sec
  ~10 packets in, 10 .. 15 packets out / sec

* server load is low
  0% CPU load with occational peeks up to 7%
  ~500MB total RAM usage (i.e. about 1.5G is used as file cache)
  disks are almost idle

* client load is low
  0 .. 5% typ. CPU usage, about half the time is at 0%
  SVN process uses ~5MB RAM
  disk is almost idle

Much more interesting:

* merge is slow (~2 secs per file) with updating, adding or
  deleting single files
* merge is fast (tens of files / sec) when adding or
  deleting whole sub-trees

My wild guess about what is happening:

* SVN client is slow when updating the item's parent entries file
  (i.e. when all other entries in that file are left unchanged)
* the is some sleep() operation involved here
  (since the seems to be no obvious bottleneck)

However, the title "extremely slow merges" sounds a bit overdone.
In most cases, where only few files get changed, the current merge
implementation is surely fast enough. Thus, a better title would be:
"Why is a merge much slower than an update?"

Hoping you find this information helpful,
Received on Wed Dec 29 18:07:56 2004

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.