39 votos

Por qué rsync es más rápido que el NFS?

Hace unos días me di cuenta de algo bastante extraño (al menos para mí). Corrí rsync copia de los mismos datos y borrar después, a punto de montaje NFS, llamado /nfs_mount/TEST. Este /nfs_mount/TEST está alojado/exportar desde nfs_server-eth1. El MTU en ambas interfaces de red es de 9000, la de cambiar entre soporta tramas jumbo así. Si hago rsync -av dir /nfs_mount/TEST/ puedo conseguir red velocidad de transferencia de X MBps. Si hago rsync -av dir nfs_server-eth1:/nfs_mount/TEST/ puedo conseguir red velocidad de transferencia de al menos 2X MBps. Mis opciones de montaje NFS son nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Línea de base: tanto las transferencias a través de la misma subred de la red, los mismos hilos, mismas interfaces, leer los mismos datos, escribir en el mismo directorio, etc. Única diferencia de que uno es a través de NFSv3, el otro sobre rsync.

El cliente es Ubuntu 10.04, el servidor de Ubuntu 9.10.

¿Cómo rsync es que mucho más rápido? Cómo hacer NFS que coincida con la velocidad?

Gracias

Edit: por favor nota que utilizar rsync para escribir en el recurso compartido NFS o SSH en el servidor NFS y escribir localmente allí. Ambas veces, me rsync -av, comenzando con clara directorio de destino. Mañana voy a probar con copia simple.

Edit2 (información adicional): varía el tamaño del Archivo de 1KB-15MB. Los archivos ya comprimidos, he intentado comprimir más de ellos sin éxito. He hecho tar.gz archivo de ese dir. Aquí está el patrón:

  • rsync -av dir /nfs_mount/TEST/ = más lento de transferencia;
  • rsync -av dir nfs_server-eth1:/nfs_mount/TEST/ = más rápido rsync con tramas jumbo activado; sin tramas jumbo es un poco más lento, pero sigue siendo significativamente más rápido que el que está directamente a NFS;
  • rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = acerca de la misma como su non-tar.gz equivalente;

Pruebas con cp y scp:

  • cp -r dir /nfs_mount/TEST/ = ligeramente más rápido que rsync -av dir /nfs_mount/TEST/ , pero sigue siendo significativamente más lento de lo rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
  • scp -r dir /nfs_mount/TEST/ = el más rápido en general, ligeramente supera rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
  • scp -r dir.tar.gz /nfs_mount/TEST/ = acerca de la misma como su non-tar.gz equivalente;

Conclusión, en base a este resultado: Para esta prueba no hay diferencia significativa si se utiliza tar.gz archivo grande o muchos pequeños. Jumbo frames o desactivar también hace que casi no hay diferencia. cp y scp más rápido que sus respectivas rsync -av equivalentes. Escrito directamente a exportados recurso compartido de NFS es significativamente más lento (al menos 2 veces) que la escritura en el mismo directorio a través de SSH, independientemente del método utilizado.

Diferencias entre cp y rsync no son pertinentes en este caso. Me decidí a probar cp y scp sólo para ver si muestran el mismo patrón y que hacen - 2X diferencia.

Como puedo usar rsync o cp en ambos casos, el yo no puede entender lo que impide NFS para llegar a la velocidad de la transferencia de los mismos comandos a través de SSH.

Cómo vienen escrito de recurso compartido de NFS es 2X más lento que hacerlo en el mismo lugar a través de SSH?

Edit3 (NFS server /etc/exports opciones): rw,no_root_squash,no_subtree_check,sync. El cliente /proc/mounts muestra: nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Muchas gracias a todos!

21voto

yulia Puntos 16

NFS es un protocolo de uso compartido, mientras que Rsync está optimizado para las transferencias de archivos; hay un montón de optimizaciones que se puede hacer cuando se sabe a priori que su objetivo es copiar archivos tan rápido como sea posible en lugar de proporcionar acceso compartido a ellos.

Esto debería ayudar: http://en.wikipedia.org/wiki/Rsync

20voto

nikolaMM94 Puntos 38

Tal vez no sea más lenta la velocidad de transferencia, pero el aumento de la latencia de escritura. Trate de montar el recurso compartido de NFS async en lugar de sincronizar y ver si se cierra la velocidad de la brecha. Cuando rsync sobre ssh, el control remoto rsync proceso escribe de forma asincrónica (rápidamente). Pero cuando se escribe en la forma sincrónica montado en nfs, las escrituras no confirmó de inmediato: el servidor NFS espera hasta que se ha alcanzado el disco (o más probable es que el caché de la controladora) antes de enviar la confirmación al cliente NFS que la escritura fue un éxito.

Si 'async' soluciona su problema, tenga en cuenta que si le pasa algo a el servidor NFS mediados de escribir que muy bien podría terminar con la inconsistencia en los datos en el disco. Mientras este montaje NFS no es el principal espacio de almacenamiento para esta (o cualquier otro) de datos, usted probablemente va a estar bien. Por supuesto que iba a estar en el mismo barco si usted tiró del enchufe en el servidor nfs durante/después de rsync sobre ssh corriendo (por ejemplo, rsync devuelve 'terminado', nfs server se bloquea, los datos no confirmados en la caché de escritura que se perdió dejando a la inconsistencia en los datos en el disco).

Aunque no es un problema con la prueba (sincronizándose nuevos datos), haga ser conscientes de que rsync sobre ssh pueden realizar importantes de la CPU y de e / s de las demandas en el servidor remoto antes de que un solo byte transferido, mientras que el cálculo de las sumas de comprobación y generación de la lista de archivos que necesitan ser actualizados.

5voto

user44746 Puntos 1

Rsync es un archivo de protocolo que las transferencias sólo los bits cambiados entre los archivos. NFS es un directorio remoto protocolo de archivo que se encarga de todo, cada vez que ... como una especie de SMB en una forma. Los dos son diferentes y para diferentes propósitos. Usted podría utilizar Rsync para la transferencia entre dos recursos compartidos de NFS.

3voto

Slartibartfast Puntos 2327

Esto es muy interesante. Una posibilidad de que usted puede no haber considerado es el contenido y tipo de archivo que está transmitiendo.

Si usted tiene montones de pequeños archivos (por ejemplo, mensajes de correo electrónico en archivos individuales), NFS, la eficacia puede estancarse debido a la no utilización de la totalidad de MTU (tal vez esto es menos probable con TCP / UDP).

Alternativamente, si usted tiene altamente compresible archivos / datos, ordenadores rápidos, y una red que no tiene la velocidad de la CPU(*), puede obtener un speedup sólo de lo implícito compresión a través de la conexión ssh.

Una tercera posibilidad es que los archivos (o una versión de la misma) ya existe en el destino. En este caso, la aceleración sería debido a que el protocolo rsync le ahorra la transferencia de los archivos.

(*) En este caso por la "velocidad", me estoy refiriendo a la velocidad a la que la CPU puede comprimir los datos en comparación con la velocidad de la red de transmisión de datos, por ejemplo, se tarda 5 segundos para enviar 5MB a través de la red, pero la CPU puede comprimir más de 5 mb a 1 mb en 1 segundo. En este caso, el tiempo de transmisión de datos comprimidos sería un poco más de 1 segundo, mientras que los datos sin comprimir es de 5 segundos.

1voto

ThorstenS Puntos 2470

Yo también uso-e "ssh sistemas de cifrado=arcfour" para aumentar el rendimiento.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: