rsync slow copy from one disk to another

I got two drives of the same model which are connected using SATA.

When benchmarking read speeds using hdparm -t /dev/sdX, speeds of about 160MB/s are returned. When benchmarking write-speed using dd if=/dev/zero of=testfile bs=1M count=500 conv=fdatasync, speeds of about 140MB/s are returned.

However, when copying a single 10GB-file using rsync --progress /mnt/hd1/file /mnt/hd2/file, the writespeed is only about 35MB/s.

Why is it so slow? How can I make it faster?

Zulakis

Posted 2013-07-01T18:54:05.580

Reputation: 1 316

What model? Are they SSDs? It is common with SSD that the write speed is some if not much lower than the read speed. – Dan D. – 2013-07-01T19:02:29.963

They are normal HDD's. When benchmarking, write speed is 140mb/s+ also. Seems to be an issue with rsync. – Zulakis – 2013-07-01T19:04:40.027

Then it is possible that the file is rather fragmented. And the seeking which wasn't covered in your benchmarks is what is restricting the transfer speed. What does filefrag /mnt/hd1/file say when ran as root? – Dan D. – 2013-07-01T19:11:17.500

"6 extends found". Is this a good or a bad value? – Zulakis – 2013-07-01T19:18:21.407

That is a good low value and that does eliminate seeking as the cause. – Dan D. – 2013-07-01T19:21:37.043

Answers

According to many sites I found while researching this issue (for example this one), this is just normal as the bottleneck of rsync usually is CPU-power.

Results with dd and cp were near the speeds I initially had benchmarked. Seems like a 2,2Ghz dual core is just not enough for hdd-speed rsync.

During further research I also found out about this:

Correct, rsync has no option to disable the post-transfer checksum completely. I implemented a patch to rsync 2.6.9 that adds an option --trust-append that limits the post-transfer checksum to the added portion, not the entire file. The patch is attached. That should be good enough, but if you really want to disable the checksum completely, just comment out the remaining sum_update calls in match.c and receiver.c .

Rsync always checksums the whole file which takes alot of time. Using the patch mentioned above I managed to increase rsync speed to about 90MB/s. Still not great, but much better then before. Sadly, the patch has not made it into the rsync-trunk.

Zulakis

Posted 2013-07-01T18:54:05.580

Reputation: 1 316

I had exactly the same issue (on Linux) , ie: 35BM/s.

Turns out rsync is CPU bound AND does not trigger the cpu ondemand governor, so the CPU is stuck on the slowest speed (800MHz in my case vs 3000MHz)

You can test by using:

cat /proc/cpuinfo | grep MHz

The fix is to tune the CPU governor.

echo "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

To make it permanent, put it in /etc/rc.local

See for explanation: http://random-linux-stuff.blogspot.co.nz/2013/01/boost-performance-of-ondemand-cpu.html

jfp

Posted 2013-07-01T18:54:05.580

Reputation: 41