Issue met snelheid SCP & RSYNC

[bassiej19]

Goedemiddag,

Ik hoop dat iemand me kan helpen met het volgende.

Situatie:
- server 1:
- Fysieke server
- Debian 8
- 1Gbit uplink naar switch
- 2 ipadressen 5.x.x.x (extern), 192.168.123.2 (intern)

- server 2
- Virtuele server (op node in datacenter (zelfde rack)).
- Debian 8
- 1Gbit uplink naar switch
- 1 ipadres intern (192.168.123.3)

Beide servers doen nagenoeg niks. (virtualisatie node doet ook nagenoeg niks)

Als ik vanaf server 2 een rsync doe (params: -r) of een scp (param -r) naar 192.168.123.2 dan krijg ik maximaal 12MB ~ 20MB (20MB is al uitzonderlijk). Files zijn allen minimaal enkele GB's per stuk.

Als ik vanaf 192.168.123.2 een wget naar 192.168.178.3 (dus downloaden via wget ipv pushen via rsync of scp), haal ik tussen de 100 & 115 MB per seconde. Hij sprint in 1 keer van 0 naar 100MB per seconde, dus bandbreedte lijkt niet het probleem.

Via TOP zie ik niks bijzonders, dus geen hoge load of iets dergelijks.

Klinkt dit iemand bekend in de oren? En wie weet er een oplossing voor.

Alvast bedankt,
Sebastiaan

[KoeKk]

Ik heb dit ook vaak gezien, ik heb het vermoeden dat het komt door de encryptie die SCP toepas (Standaard Triple-DES meen ik), doe je de rsync heel toevallig over een SSH tunnel?

Oh en kijk eens via TOP welk proces op dat moment dan de meeste CPU pakt? Dikke kans dat je load <1 is, maar dat SCP toch de meeste CPU vreet

[ Voor 28% gewijzigd door KoeKk op 20-10-2016 15:37 ]

[bassiej19]

RSYNC en SCP usage is idd het hoogste. Maar hij hangt ruim onder de 1. Ook qua percentage is hij bijna 87% idle.

Ze beschikken beiden over 4 cores.

Qua rsync? Wat bedoel je exact met tunnel? Ik leg er niet los een SSH tunnel voor aan, maar doe het wel over SSH volgens mij:

rsync -r map/ -e 'ssh -p xx' user@192.168.123.2:/storage/
&
scp -rP xx map/ user@192.168.123.2:/storage/

[rippiedoos]

Heb je al eens een iperf gedaan tussen beide omgevingen om te kijken of je ECHT wel gbit haalt? En dat er niet stiekem ergens een 100mbit-component tussen hangt?

En die virtuele server, wat voor virtualisatie is dat? Heb je al op de hypervisor daar gekeken of dat daar nog iets tegen een bottleneck aanloopt?

Verder zou je bij scp/rsync als encryptie arcfour kunnen pakken, die is speciaal voor streaming en heeft lekker weinig overhead. Nog beter is als cipher (optie -c) aes128-cbc en mac (optie -m) [e-mail] gebruiken. Moderne Xeons hebben daarvoor HW-offloading. Dus ook trage CPU's kunnen dan wirespeed SCP'en.

[KoeKk]

Ja dan doe je het inderdaad over SSH heen, en dus ook met de encryptie. Rsync over SSH zou sneller moeten zijn dan SCP omdat het maar 1 connectie opzet, terwijl bij SCP er per file een connectie opgezet wordt.
Verder is SCP (of SSH) niet geoptimaliseerd voor hoge snelheden, het heeft nogal lage buffers wat het allemaal wat traag maakt.

@rippiedoos: Hij haalt met wget 100 / 115 MB/s, dus gbit snelheid

Oh en de encryptie methode aanpassen kan inderdaad ook helpen.

[ Voor 7% gewijzigd door KoeKk op 20-10-2016 16:08 ]

[rippiedoos]

Ah, overheen gelezen over die wget. My bad!

[bassiej19]

Bedankt allen voor de reacties.

Ik heb rsync deze opties toegevoegd "-T -c arcfour -o Compression=no -x".

Oude situatie:
- start met 8MB
- krabbelt op naar 15MB

Nieuwe situatie:
- Start met 65MB
- Krabbelt af naar 15MB

Wget diverse files getest wederom. Tot aan 8GB per stuk. Dit doet hij netjes binnen 80 seconde. Dus daar is hij echt continue stabiel boven de 100MB per sec.

[KoeKk]

Ik denk dat er niet veel aan te doen is. Ik zie precies hetzelfde gebeuren in mijn situatie (ook een gbit server omgeving, met zowel FreeBSD als CentOS), en als SCP/SSH kleine buffers gebruikt dan ga je niets zien in TOP, maar is het toch traag.

Mogelijk een andere tunnel methode gebruiken dan SSH/SCP? Ik weet zelf dat ik over IPSEC VPN's wel 'linespeed minus overhead' haal, maar de vraag is dan of dat dan een wat zware oplossing is. Ik heb mijzelf er bij neergelegd dat scp traag is, ;-)

[DJVG]

Wil je perse de boel over een veilige verbinding laten verlopen? Je kan ook rsync aan beide kanten gebruiken.

[bassiej19]

DJVG schreef op donderdag 20 oktober 2016 @ 17:37:
Wil je perse de boel over een veilige verbinding laten verlopen? Je kan ook rsync aan beide kanten gebruiken.

Bedankt voor je reactie. Encryptie is niet vereist. Het gaat over ongevoelige data en het is ook nog eens een intern netwerk.

Zijn er alternatieven ten opzichte van rsync en scp die naar ervaring wel beter werken?

Sebastiaan

[DJVG]

bassiej19 schreef op donderdag 20 oktober 2016 @ 18:32:
[...]


Bedankt voor je reactie. Encryptie is niet vereist. Het gaat over ongevoelige data en het is ook nog eens een intern netwerk.

Zijn er alternatieven ten opzichte van rsync en scp die naar ervaring wel beter werken?

Sebastiaan

Mijn ervaring is dat rsync razendsnel is zolang je het niet over ssh doet en dus gewoon een rsync daemon op de doel host heb draaien. Zie de man page van rsyncd.conf: https://linux.die.net/man/5/rsyncd.conf

[Koffie]

Move PNS > NT