Greetings-
The subject sums it up...
I have a Dell 2950 acting as a general purpose 'storage' machine, handling some NFS work for some local servers, and also pulling in rsync backups of some largish filesystems over SSH. These backups, prior to the upgrade were taking about 6 hours to complete (MANY small files). Now, after the upgrade, the same backups are taking about 16 hours to complete. The actual storage array in question (PERC 5i running RAID5) has not changed in any way, nor the filesystem (ext3). The only hardware change was an upgrade from 2GB to 16GB of RAM.
Are there any issues with the filesystem being created by a 32bit OS, now used on a 64bit OS? I find it hard to believe rsync has gotten 'slower' in later versions.. :)
All tips, pointers, suggestions, etc welcome.
--Tim
On 10/16/2012 05:54 AM, Tim Nelson wrote:
All tips, pointers, suggestions, etc welcome.
When you're rsync'ing, what does top (on source and destination) say?
Is ssh or rsync using a lot of CPU?
Mogens
On Mon, Oct 15, 2012 at 10:54 PM, Tim Nelson tnelson@rockbochs.com wrote:
I have a Dell 2950 acting as a general purpose 'storage' machine, handling some NFS work for some local servers, and also pulling in rsync backups of some largish filesystems over SSH. These backups, prior to the upgrade were taking about 6 hours to complete (MANY small files). Now, after the upgrade, the same backups are taking about 16 hours to complete. The actual storage array in question (PERC 5i running RAID5) has not changed in any way, nor the filesystem (ext3). The only hardware change was an upgrade from 2GB to 16GB of RAM.
Are there any issues with the filesystem being created by a 32bit OS, now used on a 64bit OS? I find it hard to believe rsync has gotten 'slower' in later versions.. :)
All tips, pointers, suggestions, etc welcome.
Could something you've done as part of the upgrade have touched the timestamps on the source or destination files? A mismatch would make rsync do a block-checksum comparison over the file contents instead of skipping things where the timestamp and length are identical. But, this should fix itself after the first run.
----- Original Message -----
Greetings-
The subject sums it up...
...
And... apparently I'm braindead. It turns out the cron job was setup incorrectly such that it was starting 10 hours later than expected, resulting in the 10 hour increase in time.
Final score is CentOS 1, me 0.
Thanks Les and Mogens for the responses!
--Tim