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

Hace unos días noté algo bastante extraño (al menos para mí). Ejecuté rsync copiando los mismos datos y eliminándolos luego al montaje NFS, llamado /nfs_mount/TEST. Esto /nfs_mount/TESTse aloja / exporta desde nfs_server-eth1. La MTU en ambas interfaces de red es 9000, el conmutador entre soportes también admite tramas gigantes. Si lo hago rsync -av dir /nfs_mount/TEST/, obtengo la velocidad de transferencia de red X MBps. Si lo hago rsync -av dir nfs_server-eth1:/nfs_mount/TEST/, obtengo una velocidad de transferencia de red 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.

En pocas palabras: ambas transferencias pasan por la misma subred de red, los mismos cables, las mismas interfaces, leen los mismos datos, escriben en el mismo directorio, etc. La única diferencia es a través de NFSv3, la otra a través de rsync.

El cliente es Ubuntu 10.04, el servidor Ubuntu 9.10.

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

Gracias

Editar: tenga en cuenta que uso rsync para escribir en NFS share o SSH en el servidor NFS y escribir localmente allí. Ambas veces lo hago rsync -av, comenzando con un claro directorio de destino. Mañana lo intentaré con copia simple.

Edit2 (información adicional): el tamaño del archivo varía de 1 KB a 15 MB. Los archivos ya están comprimidos, intenté comprimirlos aún más sin éxito. Hice un tar.gzarchivo de eso dir. Aquí está el patrón:

• rsync -av dir /nfs_mount/TEST/ = transferencia más lenta;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= rsync más rápido con marcos jumbo habilitados; sin tramas gigantes es un poco más lento, pero sigue siendo significativamente más rápido que el que está directamente en NFS;
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = aproximadamente lo mismo que su equivalente no tar.gz;

Pruebas con cpy scp:

• cp -r dir /nfs_mount/TEST/= ligeramente más rápido que, rsync -av dir /nfs_mount/TEST/pero aún significativamente más lento que rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
• scp -r dir /nfs_mount/TEST/= más rápido en general, supera ligeramente rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = aproximadamente lo mismo que su equivalente no tar.gz;

Conclusión, basada en estos resultados: para esta prueba no hay una diferencia significativa si se usa tar.gz archivo grande o muchos archivos pequeños. Los marcos jumbo activados o desactivados tampoco hacen casi ninguna diferencia. cpy scpson más rápidos que sus respectivos rsync -avequivalentes. Escribir directamente en el recurso compartido NFS exportado es significativamente más lento (al menos 2 veces) que escribir en el mismo directorio a través de SSH, independientemente del método utilizado.

Las diferencias entre cpy rsyncno son relevantes en este caso. Decidí probar cpy scpsolo para ver si muestran el mismo patrón y lo hacen, 2 veces la diferencia.

Mientras uso rsynco cpen ambos casos, no puedo entender qué impide que NFS alcance la velocidad de transferencia de los mismos comandos a través de SSH.

¿Cómo es que escribir en NFS share es 2 veces más lento que escribir en el mismo lugar a través de SSH?

Edit3 (NFS servidor / etc / exportaciones opciones): rw,no_root_squash,no_subtree_check,sync. / Proc / mounts muestra del cliente: 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.

¡Gracias a todos!

Tal vez no sea una velocidad de transferencia más lenta, sino una mayor latencia de escritura. Intente montar el recurso compartido NFS asíncrono en lugar de sincronizar y vea si eso cierra la brecha de velocidad. Cuando rsync sobre ssh, el proceso de rsync remoto escribe de forma asíncrona (rápidamente). Pero al escribir en el recurso compartido nfs montado sincrónicamente, las escrituras no se confirman de inmediato: el servidor NFS espera hasta que lleguen al disco (o más probablemente a la caché del controlador) antes de enviar la confirmación al cliente NFS de que la escritura fue exitosa.

Si 'async' soluciona su problema, tenga en cuenta que si algo le sucede al servidor NFS a mitad de la escritura, podría terminar con datos inconsistentes en el disco. Mientras este montaje NFS no sea el almacenamiento principal para esta (o cualquier otra) información, probablemente estará bien. Por supuesto, estaría en el mismo barco si desconectara el servidor nfs durante / después de rsync-over-ssh ejecutado (p. Ej., Rsync devuelve 'terminado', el servidor nfs falla, los datos no confirmados en la caché de escritura ahora se pierden dejando datos inconsistentes en el disco).

Aunque no es un problema con su prueba (rsyncing de datos nuevos), tenga en cuenta que rsync a través de ssh puede generar importantes demandas de CPU y E / S en el servidor remoto antes de que se transfiera un solo byte mientras calcula sumas de comprobación y genera la lista de archivos que deben ser actualizado.

NFS es un protocolo para compartir, mientras que Rsync está optimizado para transferencias de archivos; Hay muchas optimizaciones que se pueden hacer cuando se sabe a priori que su objetivo es copiar los archivos lo más rápido posible en lugar de proporcionarles acceso compartido.

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

Rsync es un protocolo de archivo que transfiere solo los bits cambiados entre archivos. NFS es un protocolo de archivo de directorio remoto que maneja todo cada vez ... algo así como una SMB de alguna manera. Los dos son diferentes y para diferentes propósitos. Puede usar Rsync para transferir entre dos recursos compartidos NFS.

Esto es interesante. Una posibilidad que quizás no haya considerado es el contenido / tipo de archivo que está transmitiendo.

Si tiene montones de archivos pequeños (por ejemplo, correos electrónicos en archivos individuales), la eficiencia de NFS puede verse afectada debido a que no utiliza la MTU completa (aunque esto es menos probable con TCP sobre UDP).

Alternativamente, si tiene archivos / datos altamente comprimibles, CPU rápidas y una red que no tiene la velocidad de la CPU (*), podría obtener una aceleración solo de la compresión implícita a través del enlace ssh.

Una tercera posibilidad es que los archivos (o una versión de los mismos) ya existan en el destino. En este caso, la aceleración se debe a que el protocolo rsync le ahorra la transferencia de los archivos.

(*) En este caso por 'velocidad', me refiero a la velocidad a la que la CPU puede comprimir datos en comparación con la velocidad a la que la red puede transmitir datos, por ejemplo, lleva 5 segundos enviar 5 MB a través del cable, pero la CPU puede comprimir esos 5 MB en 1 MB en 1 segundo. En este caso, el tiempo de transmisión de datos comprimidos sería ligeramente superior a 1 segundo, mientras que los datos sin comprimir son de 5 segundos.

También uso -e "ssh Ciphers = arcfour" para aumentar el rendimiento.

Si su objetivo es simplemente copiar todos los archivos de un lugar a otro, entonces tar / netcat será la opción más rápida. Si sabe que tiene muchos espacios en blanco en sus archivos (ceros), utilice la opción -i.

FUENTE: tar cvif - / ruta / a / fuente | nc DESTINO PORTAL DESTINO: cd / ruta / a / fuente && nc -l PORTNUM | tar xvif -

si sabe que sus datos son comprimibles, utilice la compresión en sus comandos tar -z -j -Ipixz

Soy fanático de pixz ... paralela xz, ofrece una gran compresión y puedo ajustar el número de CPU que tengo al ancho de banda de la red. si tengo un ancho de banda más lento, usaré una compresión más alta, así que espero en la CPU más que en la red ... si tengo una red rápida, usaré una compresión muy baja:

FUENTE: tar cvif - / ruta / a / fuente | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, ignore los ceros, compresión de nivel 2 pixz usando 12 núcleos de CPU DESTINO: nc -l PORTNUM | tar -Ipixz -xvif

si ajusta el nivel de compresión y los núcleos correctamente, dependiendo de su conjunto de datos, debería poder mantener la red cerca de saturada y hacer suficiente compresión, su cuello de botella se convierte en el disco (generalmente el lado de escritura si los sistemas de disco de lectura y escritura son lo mismo).

En cuanto a rsync, creo que omite los ceros de manera similar a como lo hace tar con esa opción, por lo que está transmitiendo menos datos que NFS. NFS no puede hacer suposiciones sobre los datos, por lo que debe transmitir cada byte junto con la sobrecarga del protocolo NFS. rsync tiene algunos gastos generales.

netcat básicamente no tiene ninguno ... enviará paquetes TCP completos que no contienen más que datos que le interesan.

con netcat, como con scp, debe enviar todos los datos de origen todo el tiempo, no puede ser selectivo como con rsync, por lo que no es adecuado para copias de seguridad incrementales o ese tipo de cosas, pero es bueno para copiar datos o archivar.

¿Tiene la configuración de bloqueo de archivos en nfsshare? Es posible que obtenga mucha más rendimiento si se deshabilita.

Supongo que el aumento de la velocidad se debe al menos en parte a que "rsync src host: / path" genera un proceso local en la máquina remota para enviar / recibir, reduciendo efectivamente su E / S por la mitad.