Suggestion for rsync speedup

Status
Not open for further replies.

Wishbringer

Cadet
Joined
Aug 22, 2014
Messages
5
After assembling an 6bay NAS with an SuperMicro ASAi-2750 (Avoton 8 cores),
I experienced poor rsync performance.
When running for example three rsync tasks (Backups, Videos, Musik) to another NAS,
I only got around 300MBit/sec. over network.
After research, I found that even when CPU is only uses around 34%, rsync threads topped single cores at 100%.
So rsync is single-threaded and don't use more than one core.
On energy-efficent NASes (C2750, J1900) this is a drawback.

Possible solution (found in www):
https://wiki.ncsa.illinois.edu/display/~wglick/Parallel+Rsync

/bin/bash
# SETUP OPTIONS
export SRCDIR="/folder/path"
export DESTDIR="/folder2/path"
export THREADS="8"

# RSYNC TOP LEVEL FILES AND DIRECTORY STRUCTURE
rsync -lptgoDvzd $SRCDIR/ /$DESTDIR/
# FIND ALL FILES AND PASS THEM TO MULTIPLE RSYNC PROCESSES
cd $SRCDIR; find . -type f | xargs -n1 -P$THREADS -I% rsync -az % /$DESTDIR/%
# IF YOU WANT TO LIMIT THE IO PRIORITY,
# PREPEND THE FOLLOWING TO THE rsync & cd/find COMMANDS ABOVE:
# ionice -c2​

over ssh:
rsync -lptgoDvzd -e 'ssh -c arcfour' $SRCDIR/ remotehost:/$DESTDIR/
cd $SRCDIR; find . -type f | xargs -n1 -P$THREADS -I% rsync -az -e 'ssh -c arcfour' % remotehost:/$DESTDIR/%​

But I am not a programmer... so posting here as a suggestion.
 

Knowltey

Patron
Joined
Jul 21, 2013
Messages
430
300Mb/s, That's actually good performance for rsync. Rsync has lots that it's doing on both ends so it does tend to be quite a bit slower than straight up file transferring. For reference I only get about 100Mb/s out of my NAS.
 

Wishbringer

Cadet
Joined
Aug 22, 2014
Messages
5
300Mb/s, That's actually good performance for rsync. Rsync has lots that it's doing on both ends so it does tend to be quite a bit slower than straight up file transferring. For reference I only get about 100Mb/s out of my NAS.

Thats it's good for rsync doesn't mean that it not couldn't be better.
Single PUSH thread is maxed out at one core, receiving client idles still at 18%.
For at C2750 that means one of eight cores is in use, all other are in vacation.

Splitting rsync tasks in several subtasks could lead to speeups for all multicore systems.
 

Knowltey

Patron
Joined
Jul 21, 2013
Messages
430
Thats it's good for rsync doesn't mean that it not couldn't be better.
Single PUSH thread is maxed out at one core, receiving client idles still at 18%.
For at C2750 that means one of eight cores is in use, all other are in vacation.

Splitting rsync tasks in several subtasks could lead to speeups for all multicore systems.
If you actually watch that over time you'll see it switches back and forth between which side is getting to most load at a given time. The side with the low is generally just confirming checksums and what not while the high side is calculating them etc.
 

Wishbringer

Cadet
Joined
Aug 22, 2014
Messages
5
If you actually watch that over time you'll see it switches back and forth between which side is getting to most load at a given time. The side with the low is generally just confirming checksums and what not while the high side is calculating them etc.

Oh, I am watching that since three days and it seems I have to wait another day for last task to finish.

Had three parallel rsync tasks (one 1TB, one 3 TB, one 5 TB).
While all three tasks were running, three cores at PUSH were at 95-100% whole the time. At the same time three threads at target were around 16-20% per core. Transfer speed was 300 MBit/Sec alltogether.
When first task was finished (1TB), now only two tasks at PUSH were at 95-100% whole the time. Same time two threads at target were aound 16-20% per core. Transfer speed was around 195 MBit/Sec. together.
Now both tasks with 1TB and 3 TB are finished, only 5TB task is still running.
And guess what: one core at 95-100% at PUSH, one core at target at around 16-20% used by rsync. And transfer speed is around 95 MBit/Sec (not that high for a Highend NAS Software).

So my suggestion was - in posted script - to enchance rsync handling at PUSH to use all cores.
So in theory it would be possible to speed up rsync sending to around 800 MBit/Sec on a C2750.
At target side CPU usage seems to be less problematic.

Other solution to speed up rsync would be to buy a better CPU (higher instructionsspeed per single core = higher frequency and better architecture),
but in my opinion, it would be sufficent to optimize software.

Example: with an i7-3770T I get around 350 MBit/Sec with one rsync-task (one core with 2.5 GHz used).
Here I could get theoretically around 1400++ MBit/Sec in parallel usage of rsync (only real cores counted, not hypertreading).

Pictures are from PUSH, that little increase of computing usage at nearly end was another task, not related to rsync

LAN-Speed
Transfer.png

CPU at PUSH
CPU.png

CPU at Target
CPU2.png
 
Last edited:
Status
Not open for further replies.
Top