CentOS - Oct 2012 - Poor rsync performance after upgrade from 5.8 x86 to 6.3 x64

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
-- 
Mogens Kjaer, mk at lemo.dk
http://www.lemo.dk

On Mon, Oct 15, 2012 at 10:54 PM, Tim Nelson <tnelson at 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.

-- 
   Les Mikesell
     lesmikesell at gmail.com

----- 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