Horrible rsync performance on wd cloud vs My book live

My Cloud OS 3 Personal & Network Attached Storage My Cloud
1

So previously i was using rysnc between two mybook live drives where rysnc daemon would run on of the drivers.

Gigabit network all around.

Now i got two my cloud drives. While Samba read write on these drives is more than 2x as the mybook live

Rsync is almost 50% slower.

rsync between the mybook live i would get 24MB/Sec… on the my clud drives i get  14-15MB/sec.

WHY IS THIS…PLEASE CAN ANYONE HELP ME

i’ve looked everywhere. im not using any compression, syncing based on size only

as rsync is cpu bound i.e if using its algorithm to determine file differences. but im not even doing that. So why is that with a dual core CPU at 1.3 ghz is slower?

Is rsync not aware of dual core?

i notice that cpu usage is only about 30% when rsync is running

2

What’s the rsync command-line you’re using?

My guess is that the SSH encryption on one end or the other is CPU-bound.

3

Thanks for the reply. As i mentioned not using anything that would use encrytpion:

 rsync -rl --progress --size-only --delete-after /shares/ nas2::shares

The same command yields 23 MB/Sec between two mybook live drives on the same switch, network etc.

Though i am using the cables that came with the drives? I guess i can try my old cheap ebay cables on the mybook live drives.

4

alirz1 wrote:

Thanks for the reply. As i mentioned not using anything that would use encrytpion:

 

 rsync -rl --progress --size-only --delete-after /shares/ nas2::shares

 

The same command yields 23 MB/Sec between two mybook live drives on the same switch, network etc.

Though i am using the cables that came with the drives? I guess i can try my old cheap ebay cables on the mybook live drives.

How are you getting rsyncd running on the Cloud?

Maybe I’m missing something implicit, but with the same commands, I get:

From the MBL to the My Cloud:

rsync: failed to connect to 10.0.0.32: Connection refused (111)

5

Its extrmely easy to get rsync going on these drives. Literally takes like 2 min.

I have the rsync daemon running on one of the cloud drives.

For the daemon to start you need to have this config realted files in pace.

Namely:

/etc/rsyncd.conf

/etc/rsync.secrets      this file can be blank, just needs to be there.

mt rsyncd.conf   file looks like this:

[shares]
path = /shares
uid = root
gid = root
read only = no
list = yes

auth users = ali

secrets file = /etc/rsyncd.secrets
hosts allow = 192.168.1.4/255.255.255.0

Then you start the daemon on that drive by running:  rsync --daemon

192.168.1.4 is the other cloud drive that initiates the rsync (thats where i run my rsync commad in the above post)

Anyways, my problem is the rsync speed compared to the mybook live setup i had before this.

2 Likes
6

Yeah, I understand the question – I was just hoping (and you answered) how you were setting it up so I can try it myself.

Give me a while, and I’ll report back.

7

Awesome thanks. Looking forward to see the result.

If possible try to rsync BIGGG files so it gives a better idea about the speed.

Thanks.

8

Ok, so I’m stupid – and shot myself in the foot.

I tried using a set of 10G - 30G BD ISO files – I was getting about 18-20Mbyte/sec going from MBL to Cloud.

I noted the SENDING end (the MBL) CPU was only about 45-50%.

But the RECEIVING end (the Cloud) CPU was pegged at 99% – most of which was RSYNC at around 89-97%.

I stopped after about 10 minutes, so the destination never got a complete set.

… and then promptly deleted the files — on the wrong end.  :laughing:

Working on restoring from backup now.  

9

oh wow (looks like i cannot SAY ) …good you had a backup… I’ve made mistakes like this once also…

ran a command once   rm-rf command like rm -f  /shares/data/ IMG *

didnt notice for a few seconds that there was a space between IMG and *… freakin thing was wiping out my entire data folder which has everything… hehe.

I did a similar test a few days ago but the other way around i.e  MBL to CLOUD. I still got the same speed.

However in all my cases/tests, the receiving device’s cpu hardly goes up from idle. Where as the sending goes up alot.

Note: receiving side is where the daemon runs in my scenario

now this gives me an another idea!! Is there a way to reverse the rsync in such a way that instead of sending data, the other drive pulls data?

10

Ok, the short answer is that RSYNC *is* CPU bound on the cloud.

It looks as if it’s only occupying one core’s-worth of CPU, not both cores, though it actually is executing on both cores.

With TOP set to CPU% breakout (press “1”), RSYNC never exceeds 100%.

It seems as though rsync executes on 1 core while IO executes on the other, and wa% is also pretty high – 70% or so.

Maybe it’s trashing the drive for some reason?

11

EXACTLY, thats what i thought also that perhaps rsync cant take advantage of both cpus. I  know in general rsync is a cpu bound process.

But still, a single core on the cloud is 1.3 ghz vs 800 on the my book. So it should still be faster.

Guess thats it then? No real way of atleast matching mybook’s performance.

Shame on you WD :cry: 

12

Well in my case, while i was rsycning a 3GB file. My IO wait times are rather low:

nas1:/shares# sar -u 2 10
Linux 3.2.26 (nas1) 10/16/13 _armv7l_ (2 CPU)

15:55:17 CPU %user %nice %system %iowait %steal %idle
15:55:19 all 22.05 0.00 20.77                   12.82       0.00 44.36
15:55:21 all 20.91 0.00 20.91                   4.53           0.00 53.65
15:55:23 all 21.73 0.00 20.16                   2.36            0.00 55.76
15:55:25 all 21.78 0.00 18.90                   0.00            0.00 59.32
15:55:27 all 20.69 0.00 19.63                   0.00            0.00 59.68
15:55:29 all 21.50 0.00 19.95                   0.00            0.00 58.55
15:55:31 all 22.42 0.00 20.40                   2.02            0.00 55.16

13

Well they better get the rsync fixed. I will not update from MBL until this and other issues are resolved. Doesn’t make sense.

14

Yeh I’m thinking if I should just return the drives.

15

whsbuss wrote:

Well they better get the rsync fixed.

Ok, I’ll bite…  Why must they?   RSYNC isn’t even an advertised component.   So why is the onus on them to fix it?

And the more I look at it, yeah, it does make sense.  Even though the Cloud is Dual Core (and beats the pants off the MBL in terms of file transfer performance), RSYNC being CPU-bound to a single core makes it slower since one individual ARMv7 core is slower than the PowerPC CPU in the MBL.

This definitely displays a weakness of rsync – it’s very CPU intensive because it computes checksums TWICE – once on each end.  THAT is what’s chewing up the CPU.

16

TonyPh12345 wrote:

whsbuss wrote:

Well they better get the rsync fixed.

Ok, I’ll bite…  Why must they?   RSYNC isn’t even an advertised component.   So why is the onus on them to fix it?

 

And the more I look at it, yeah, it does make sense.  Even though the Cloud is Dual Core (and beats the pants off the MBL in terms of file transfer performance), RSYNC being CPU-bound to a single core makes it slower since one individual ARMv7 core is slower than the PowerPC CPU in the MBL.

 

This definitely displays a weakness of rsync – it’s very CPU intensive because it computes checksums TWICE – once on each end.  THAT is what’s chewing up the CPU.

 

Isn’t rsync the basis for their Safepoint utility? I know it is in my MBL. Maybe someone can verify if safepoint in the MyCloud is slower than MBL.

17

whsbuss wrote:

Isn’t rsync the basis for their Safepoint utility? I know it is in my MBL. Maybe someone can verify if safepoint in the MyCloud is slower than MBL.

 Yes and no.  What’s being duscussed above is a simple rsync using the rsync process at the client (with specific options) as well as rsync daemon at the receiver.  

 The safepoint process doesn’t use the rsync daemon at the receiver - it uses Samba as a transport.   So the receiver isn’t doing much of anything during a Safepoint.  The only process with higher CPU is smbd; and the Cloud was only about 30-40% CPU while the safepoint was running.   Above, the CPU was 100%.  It also appears that, on the sender, it’s not a single-threaded process as it is above.   It uses multiple instances of rsync at the sender:

MyBookLive:~# ps aux | grep rsync
root 30167 0.0 1.2 4992 3072 ? S< 07:42 0:00 sh -c rsync -rtDviH --delete --progress --exclude-from "/etc/nas/NSPT/exclude.txt" --delete-excluded "/DataVolume/shares/" "/media/WDSAFE/d33ff19d3bd08a45392b41ad525fdb3f//_WDPROT/WDSAFE/TesttoDUO/shares" 2> /dev/null
root 30168 10.5 4.3 25792 10944 ? S< 07:42 0:01 rsync -rtDviH --delete --progress --exclude-from /etc/nas/NSPT/exclude.txt --delete-excluded /DataVolume/shares/ /media/WDSAFE/d33ff19d3bd08a45392b41ad525fdb3f//_WDPROT/WDSAFE/TesttoDUO/shares
root 30169 1.6 3.9 21504 9984 ? S< 07:42 0:00 rsync -rtDviH --delete --progress --exclude-from /etc/nas/NSPT/exclude.txt --delete-excluded /DataVolume/shares/ /media/WDSAFE/d33ff19d3bd08a45392b41ad525fdb3f//_WDPROT/WDSAFE/TesttoDUO/shares
root 30170 12.3 4.0 25728 10368 ? D< 07:42 0:01 rsync -rtDviH --delete --progress --exclude-from /etc/nas/NSPT/exclude.txt --delete-excluded /DataVolume/shares/ /media/WDSAFE/d33ff19d3bd08a45392b41ad525fdb3f//_WDPROT/WDSAFE/TesttoDUO/shares
root 30307 0.0 0.6 3648 1600 pts/0 S+ 07:42 0:00 grep rsync
18

Quesiton on these safepoints. I’ve never used them.

Is a safe point like a system image as in like a one big zipped up file type of thing or is the data structure the same as the source drive. By that i mean, can you simply access the files like you do on a regular mapped drive?

If thats the case, i could simply use the safe point feature. But i have a feeling that that process doesnt just update changed data, rather it copies everything all over?

19

alirz1 wrote:

Quesiton on these safepoints. I’ve never used them.

Is a safe point like a system image as in like a one big zipped up file type of thing or is the data structure the same as the source drive. By that i mean, can you simply access the files like you do on a regular mapped drive?

It’s the same structure, but in a different place.   It stores them in in a share you choose.

Yes, you can access the files via a mapped drive.

I don’t think it’s doing block-level change-data via Safepoint, but it is NOT resending files that are already present.

20

So if the same file or folder changes e.g a word doc or folder gets updated that won’t get backed up with the safe point.?