Solución 1:
Las razones pueden incluir:la compresión, el cifrado, la cantidad y el tamaño de los archivos que se copian, las capacidades de E/S del disco de los sistemas de origen y de destino, la sobrecarga de TCP... Todos estos son factores que pueden influir en el tipo de transferencia que está realizando.
Publique el comando rsync que está utilizando y proporcione detalles sobre las especificaciones de ambas computadoras.
Editar:el cifrado suele ser un factor limitante en las velocidades de rsync. Puede ejecutar con ssh y un cifrado de cifrado más ligero como arcfour
Algo como:rsync -e "ssh -c arcfour"
O puede usar un rsync/ssh modificado que puede deshabilitar el cifrado. Consulte hpn-ssh:http://psc.edu/networking/projects/hpn-ssh
Pero nuevamente, su computadora portátil tiene un disco lento en comparación con su estación de trabajo. Las escrituras pueden estar bloqueadas y esperando que la E/S vaya a su computadora portátil. ¿Cuáles son sus expectativas reales de rendimiento?
Solución 2:
Otra forma de mitigar el alto uso de la CPU pero aún así mantener la funcionalidad de rsync es pasar de rsync/SSH a rsync/NFS. Puede exportar las rutas desde las que desea copiar a través de NFS y luego usar rsync localmente desde el montaje NFS a su ubicación de destino.
En una prueba de un disco de red WD MyBook Live, uno o más rsyncs del NAS en una red Gigabit hacia 2 discos USB locales no copiaron más de 10 MB/seg (CPU:80 % usr, 20 % sys), después de exportar NFS y rsyncing localmente desde el recurso compartido de NFS a ambos discos, obtuve un total de 45 MB/s (máximo de ambos discos USB2) y poco uso de la CPU. La utilización del disco al usar rsync/SSH fue de alrededor del 6 % y al usar rsync/NFS estuvo más cerca del 24 %, mientras que ambos discos USB2 estuvieron cerca del 100 %.
Así que trasladamos efectivamente el cuello de botella de la CPU NAS a ambos discos USB2.
Solución 3:
Después de algunas pruebas más, finalmente encontré la respuesta yo mismo. rsync usa tunelización sobre ssh por defecto. La criptografía lo hace lento. Así que necesitaba sortear esas cosas criptográficas.
Solución 1:configurar un servidor rsync
Para usarlo a través del rsync protocolo, debe configurar un servidor rsyncd. Había un /etc/init.d/rsync script en mi computadora portátil, así que supuse que rsyncd se estaba ejecutando. Estaba equivocado. /etc/init.d/rsync start existe en silencio, cuando rsync no está habilitado en /etc/default/rsync . Luego también hay que configurarlo en /etc/rsyncd.conf , que es un dolor.
Si logras hacer todo esto, debes usar rsync file.foo [email protected]::directory . Tenga en cuenta que hay dos puntos .
Solución 2:servidor rsh de la vieja escuela
Sin embargo, la configuración era demasiado complicada para mí. Así que acabo de instalar y rsh-server en mi ordenador portátil. Invocar rsync en la estación de trabajo con -e rexec luego usa rsh en lugar de ssh. Que luego casi duplicó el rendimiento a 44,6 MB/s , que sigue siendo lento. La velocidad rebota entre 58 MB/s y 33 MB/s , lo que indica que puede haber algunos problemas de control de congestión o búfer. Pero eso está más allá del alcance de esta pregunta.
Solución 4:
Estas son preguntas y respuestas muy antiguas, pero falta una cosa importante:si está copiando datos ya comprimidos o cifrados, desactive la compresión.
Si sus datos no están comprimidos ni encriptados, ¡solo querrá comprimirlos una vez! Rsync comprime con -z, ssh comprime con -C (puede ser por defecto). No he probado cuál es mejor ya que mis datos están comprimidos.
Mientras estoy en eso, puede desactivar el reenvío de X y la asignación de TTY, lo que da como resultado:
rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst
Por último, asegúrese (por ejemplo, usando iptraf ) que en realidad está utilizando la interfaz de red que cree que está utilizando. Para mi gran sorpresa, noté que en mi OSX, el ssh saliente se vinculaba a la IP en la interfaz de salida predeterminada en lugar de a la IP en la interfaz en la que se suponía que los paquetes debían enrutarse. Mi conexión cruzada directa de GB entre dos computadoras portátiles también conectadas por WiFi no se estaba utilizando. Después de la investigación, se debió al uso de 169.254/16, que la Mac coloca en todas las interfaces, y la computadora de destino respondió a las solicitudes ARP aunque la solicitud llegó en una interfaz diferente.