You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by St...@etas.de on 2004/12/29 16:36:23 UTC

Re: Extremely slow merges

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,
Stefan.

Re: Extremely slow merges

Posted by John Peacock <jp...@rowman.com>.
Stefan.Fuhrmann@etas.de wrote:
> 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

What antivirus software are you running on the client?  Can you temporarily 
uninstall it (disabling may not be enough) and rerun the test?

The reason I ask is that the hooks that AV software use on Win32 platforms are 
very deep into the system.  These callbacks have an almost pathelogical effect 
on software which creates lots of temporary files then renames them (exactly 
what Subversion and for that matter CVSNT both do).  Disabling the AV software 
merely makes the callbacks return immediately, but still leaves the callback 
hooks in place, thus still slowing down the file access.

John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org