Řešení 1:
Důvody mohou zahrnovat:komprese, šifrování, počet a velikost kopírovaných souborů, možnosti I/O disku vašeho zdrojového a cílového systému, režie TCP... To vše jsou faktory, které mohou ovlivnit typ přenosu, který provádíte.
Zveřejněte prosím příkaz rsync, který používáte, a uveďte podrobnosti o specifikacích obou počítačů.
Edit:Šifrování je často limitujícím faktorem rychlosti rsync. Můžete spustit ssh a lehčí šifrovací šifru, jako je arcfour
Něco jako:rsync -e "ssh -c arcfour"
Nebo můžete použít upravený rsync/ssh, který umí zakázat šifrování. Viz hpn-ssh:http://psc.edu/networking/projects/hpn-ssh
Ale opět, váš notebook má ve srovnání s vaší pracovní stanicí pomalý disk. Zápisy mohou být blokovány a čekají na vstup/výstup do vašeho notebooku. Jaká jsou vaše skutečná očekávání ohledně výkonu?
Řešení 2:
Dalším způsobem, jak zmírnit vysoké využití CPU, ale přesto zachovat funkčnost rsync, je přechod z rsync/SSH na rsync/NFS. Cesty, ze kterých chcete kopírovat, můžete exportovat přes NFS a poté lokálně použít rsync z připojení NFS do cílového umístění.
V jednom testu ze síťového disku WD MyBook Live by jeden nebo více rsync z NAS v gigabitové síti směrem ke 2 místním USB diskům nekopírovalo více než 10 MB/s (CPU:80 % usr, 20 % sys), po exportu přes NFS a rsyncing lokálně ze sdíleného NFS na oba disky Získal jsem celkem 45 MB/s (maximum oba USB2 disky) a malé využití CPU. Využití disku při použití rsync/SSH bylo asi 6 % a použití rsync/NFS bylo blíže 24 %, zatímco oba USB2 disky se blížily 100 %.
Takže jsme efektivně přesunuli úzké hrdlo z CPU NAS na oba USB2 disky.
Řešení 3:
Po nějakém dalším testování jsem konečně našel odpověď sám. rsync standardně používá tunelování přes ssh. Díky kryptoměnám je to pomalé. Takže jsem potřeboval obejít ty krypto věci.
Řešení 1:Nastavení serveru rsync
Chcete-li jej použít prostřednictvím rsync protokolu, musíte nastavit server rsyncd. Bylo tam /etc/init.d/rsync skript na mém notebooku, takže jsem uhádl, že běží rsyncd. Mýlil jsem se. /etc/init.d/rsync start existuje tiše, když rsync není povolen v /etc/default/rsync . Potom jej také musíte nakonfigurovat v /etc/rsyncd.conf , což je bolest.
Pokud toto všechno zvládnete, musíte použít rsync file.foo [email protected]::directory . Upozorňujeme, že existují dvě dvojtečky .
Řešení 2:Oldschoolový rsh-server
Konfigurace na mě však byla příliš složitá. Tak jsem právě nainstaloval a rsh-server na mém notebooku. Vyvolání rsync na pracovní stanici s -e rexec pak použije rsh místo ssh. Což pak výkon téměř zdvojnásobilo na 44,6 MB/s , která je stále pomalá. Rychlost se pohybuje mezi 58 MB/s a 33 MB/s , což naznačuje, že mohou nastat problémy s vyrovnávací pamětí nebo řízením zahlcení. Ale to je nad rámec této otázky.
Řešení 4:
Toto jsou velmi staré otázky a odpovědi, ale chybí jedna důležitá věc:pokud kopírujete již zkomprimovaná nebo zašifrovaná data, vypněte kompresi.
Pokud vaše data nejsou ani komprimovaná, ani šifrovaná, stále je chcete komprimovat pouze jednou! Rsync komprimuje s -z, ssh komprimuje s -C (může být ve výchozím nastavení). Netestoval jsem, co je lepší, protože moje data jsou komprimovaná.
Když už jsem u toho, můžete vypnout X forwarding a TTY alokaci, což má za následek:
rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst
Nakonec se ujistěte (například pomocí iptraf ), že skutečně používáte síťové rozhraní, které si myslíte, že používáte. Ke svému velkému překvapení jsem si všiml, že na mém OSX se odchozí ssh vázal na IP na výchozím odchozím rozhraní místo na IP na rozhraní, na které měly být pakety směrovány. Moje přímé křížové propojení GB mezi dvěma notebooky připojenými také přes WiFi nebylo používáno. Po prošetření to bylo způsobeno použitím 169.254/16, které Mac umístí na všechna rozhraní, a tím, že cílový počítač odpovídá na požadavky ARP, i když požadavek přišel na jiném rozhraní.