sync performance falls off a cliff

Mike Connell mikefconnell at
Tue Jun 30 04:26:41 GMT 2009


I've got identical servers. One is primary the other is backup
receiving rsyncs from the primary. I'm backing up a file system to
disk and the files are small and there are lots of directories.

The overall problem seems to be the total number of files.
When I had ~375,000 files, the total rsync time was under a minute.
With ~425,000 files, the total rsync time is 10 minutes.

Last Friday when we were at 425,000 files, the rsync time was 10 minutes.
Today I was able to delete 50,000 unneeded files and the rsync time went
back down to under a minute.

So why the huge change in total rsync time for a somewhat small change
in total number of files? I'm afraid that as the total number of files keeps
increasing that the total rsync time is going to go exponential.

I turn the --progress flag on, and the time is rougly divided up evenly between
building the file list and looking thru the file list. The files themselves
are really small (~16K) and I'm not seeing any problem with anything
other than how long it takes rsync to make a pass thru all the files. I do use
the --delete option.

The servers are Dell 2950s, builtin RAID 10 disks and 4Gig of RAM.
OS is Centos 5.1. I'm running rsync 2.6.8 protocol version 29.

This smells to me like some sort of caching problem. Is there something
in the kernel or rsync itself that I can tweek?


-------------- next part --------------
HTML attachment scrubbed and removed

More information about the rsync mailing list