Rsync más rápido de gran directorio que no se modificó

13

Usamos rsync para hacer copias de seguridad de los servidores.

Lamentablemente, la red para algunos servidores es lenta.

Rsync tarda hasta cinco minutos en detectar que nada ha cambiado en directorios enormes. Estos enormes árboles de directorios contienen muchos archivos pequeños (alrededor de 80k archivos).

Supongo que los clientes rsync envían datos para cada uno de los 80k archivos.

Como la red es lenta, me gustaría evitar enviar información de 80k veces sobre cada archivo.

¿Hay alguna manera de decirle a rsync que haga una suma hash de un árbol de subdirectorio?

De esta forma, el cliente rsync enviaría solo unos pocos bytes para un gran árbol de directorios.

Actualizar

Hasta ahora mi estrategia es usar rsync. Pero si una herramienta diferente encaja mejor aquí, puedo cambiar. Ambos (servidor y cliente) están bajo mi control.

Actualización2

Hay 80k archivos en un árbol de directorios . Cada directorio no tiene más de 2k archivos o subdirectorios

Actualización3

Detalles sobre la lentitud de la red:

time ssh einswp 'cd attachments/200 && ls -lLR' >/tmp/list
real    0m2.645s

Tamaño del archivo tmp / list: 2 MByte

time scp einswp:/tmp/list tmp/
real    0m2.821s

Conclusión: scp tiene la misma velocidad (no es de extrañar)

time scp einswp:tmp/100MB tmp/
real    1m24.049s

Velocidad: 1.2 MB / s

rsync synchronization guettli
fuente
1
Puede leer en zsync. No lo he usado yo mismo, pero por lo que leí, renderiza previamente los metadatos en el lado del servidor y podría acelerar las transferencias en su caso. Puede valer la pena probar de todos modos. Más allá de eso, la única otra solución que conozco es la sincronización de nivel de bloque en tiempo real que viene con algunas soluciones san / nas.
Aaron

Respuestas:

36

Algunos puntos no relacionados:

80K es muchos archivos.

¿80,000 archivos en un directorio? Ningún sistema operativo o aplicación maneja esa situación muy bien por defecto. Simplemente se da cuenta de este problema con rsync.

Comprueba tu versión de rsync

Modern rsync maneja directorios grandes mucho mejor que en el pasado. Asegúrese de estar utilizando la última versión.

Incluso el antiguo rsync maneja directorios grandes bastante bien a través de enlaces de alta latencia ... pero los archivos de 80k no son grandes ... ¡son enormes!

Dicho esto, el uso de memoria de rsync es directamente proporcional al número de archivos en un árbol. Los directorios grandes requieren una gran cantidad de RAM. La lentitud puede deberse a la falta de RAM en ambos lados. Haga una prueba de funcionamiento mientras observa el uso de la memoria. Linux utiliza cualquier RAM restante como caché de disco, por lo que si se está quedando sin RAM, hay menos almacenamiento en caché de disco. Si se queda sin RAM y el sistema comienza a usar el intercambio, el rendimiento será realmente malo.

Asegúrese de que --checksum no se esté utilizando

--checksum(o -c) requiere leer cada bloque de cada archivo. Probablemente pueda sobrevivir con el comportamiento predeterminado de solo leer los tiempos de modificación (almacenados en el inodo).

Divide el trabajo en pequeños lotes.

Hay algunos proyectos como Gigasync que " cortará la carga de trabajo usando perl para repetir el árbol de directorios, creando pequeñas listas de archivos para transferir con rsync".

El escaneo de directorio adicional será una gran cantidad de gastos generales, pero tal vez sea una ganancia neta.

Los valores predeterminados del sistema operativo no están hechos para esta situación.

Si está utilizando Linux / FreeBSD / etc con todos los valores predeterminados, el rendimiento será terrible para todas sus aplicaciones. Los valores predeterminados suponen directorios más pequeños para no desperdiciar RAM en cachés de gran tamaño.

Ajuste su sistema de archivos para manejar mejor los directorios grandes: ¿Los tamaños de las carpetas grandes disminuyen el rendimiento de las E / S?

Mira el "nombre de caché"

Los sistemas operativos tipo BSD tienen un caché que acelera la búsqueda de un nombre para el inodo (el "namei" caché "). Hay un caché namei para cada directorio. Si es demasiado pequeño, es un obstáculo más que una optimización. Dado que rsync está haciendo un lstat () en cada archivo, se accede al inodo para cada uno de los 80k archivos. Eso podría estar volcando su caché. Investigue cómo ajustar el rendimiento del directorio de archivos en su sistema.

Considere un sistema de archivos diferente

XFS fue diseñado para manejar directorios más grandes. Ver gran cantidad de archivos del sistema de archivos en un solo directorio

Quizás 5 minutos es lo mejor que puedes hacer.

Considere calcular cuántos bloques de disco se están leyendo y calcule qué tan rápido debe esperar que el hardware pueda leer tantos bloques.

Quizás tus expectativas sean demasiado altas. Considere cuántos bloques de disco deben leerse para hacer una sincronización sin archivos modificados: cada servidor necesitará leer el directorio y leer un inodo por archivo. Supongamos que nada está en caché porque, bueno, 80k archivos probablemente han volado su caché. Digamos que son 80k bloques para mantener las matemáticas simples. Eso es alrededor de 40 millones de datos, que deberían ser legibles en unos segundos. Sin embargo, si debe haber una búsqueda de disco entre cada bloque, eso podría llevar mucho más tiempo.

Por lo tanto, tendrá que leer unos 80,000 bloques de disco. ¿Qué tan rápido puede hacer eso tu disco duro? Teniendo en cuenta que esta es una E / S aleatoria, no una lectura lineal larga, 5 minutos podrían ser bastante excelentes. Eso es 1 / (80000/600), o un disco leído cada 7,5 ms. ¿Eso es rápido o lento para su disco duro? Depende del modelo.

Benchmark contra algo similar

Otra forma de pensarlo es esta. Si no ha cambiado ningún archivo, ls -Llrrealiza la misma cantidad de actividad de disco pero nunca lee ningún dato de archivo (solo metadatos). El tiempo que ls -Llrlleva correr es su límite superior.

  • ¿Es rsync (sin archivos cambiados) significativamente más lento que ls -Llr? Luego, las opciones que está utilizando para rsync se pueden mejorar. Quizás -cesté habilitado o algún otro indicador que lea más que solo directorios y metadatos (datos de inodo).

  • ¿Es rsync (sin archivos cambiados) casi tan rápido como ls -Llr? Entonces has sintonizado rsync lo mejor que puedes. Debe ajustar el sistema operativo, agregar RAM, obtener unidades más rápidas, cambiar los sistemas de archivos, etc.

Habla con tus desarrolladores

80k archivos es simplemente un mal diseño. Muy pocos sistemas de archivos y herramientas del sistema manejan directorios tan grandes muy bien. Si los nombres de archivo son abcdefg.txt, considere almacenarlos en abdc / abcdefg.txt (tenga en cuenta la repetición). Esto divide los directorios en pequeños, pero no requiere un gran cambio en el código.

Además ... considere usar una base de datos. Si tiene 80k archivos en un directorio, tal vez sus desarrolladores estén trabajando en el hecho de que lo que realmente quieren es una base de datos. MariaDB o MySQL o PostgreSQL sería una opción mucho mejor para almacenar grandes cantidades de datos.

Oye, ¿qué pasa con 5 minutos?

Por último, ¿son realmente tan malos 5 minutos? Si ejecuta esta copia de seguridad una vez al día, 5 minutos no es mucho tiempo. Sí, amo la velocidad. Sin embargo, si 5 minutos es "lo suficientemente bueno" para sus clientes, entonces es lo suficientemente bueno para usted. Si no tiene un SLA escrito, ¿qué tal una discusión informal con sus usuarios para averiguar qué tan rápido esperan que se realicen las copias de seguridad?

Supongo que no hizo esta pregunta si no era necesario mejorar el rendimiento. Sin embargo, si sus clientes están contentos con 5 minutos, declare la victoria y pase a otros proyectos que necesiten su esfuerzo.

Actualización: Después de algunas discusiones, determinamos que el cuello de botella es la red. Voy a recomendar 2 cosas antes de renunciar :-).

  • Intente exprimir más ancho de banda de la tubería con compresión. Sin embargo, la compresión requiere más CPU, por lo que si su CPU está sobrecargada, podría empeorar el rendimiento. Pruebe rsync con y sin -z, y configure su ssh con y sin compresión. Calcula las 4 combinaciones para ver si alguna de ellas funciona significativamente mejor que otras.
  • Observe el tráfico de red para ver si hay pausas. Si hay pausas, puede encontrar lo que las está causando y optimizarlas allí. Si rsync siempre está enviando, entonces realmente estás en tu límite. Sus elecciones son:
    • una red más rápida
    • algo diferente a rsync
    • mover el origen y el destino más cerca juntos. Si no puede hacer eso, ¿puede rsync a una máquina local y luego rsync al destino real? Puede haber beneficios al hacer esto si el sistema tiene que estar inactivo durante la sincronización inicial.
TomOnTime
fuente
80K son muchos archivos .: Hay 80k archivos en un árbol de directorios . Cada directorio no tiene más de 2k archivos / subdirectorios.
guettli
Verifique su versión de rsync: hecho, asegúrese de que --checksum no se esté usando: hecho. Divida el trabajo en pequeños lotes: Gracias, echaré un vistazo a gigasync. Los valores predeterminados del sistema operativo no están hechos para esta situación: hecho (el cuello de botella es la red, no el sistema operativo). Mire el "nombre de caché": hecho (es neto, no SO). Considere un sistema de archivos diferente: nuevamente net, no OS. Quizás 5 minutos es lo mejor que puedes hacer: creo que podría ser mucho más rápido. Hable con sus desarrolladores (use DB): este sería un cambio gigante. Tal vez un sistema de archivos con mejor soporte de respaldo lo resolvería.
guettli
2k archivos por directorio es mucho mejor. gracias por la actualizacion. No habías mencionado que la red era lenta. ¿Es bajo ancho de banda, alta latencia o ambos? rsync generalmente funciona bien en enlaces de alta latencia (fue desarrollado por alguien que trabaja en su doctorado de Australia mientras trabajaba con computadoras en los Estados Unidos). Intenta hacer eso "ls -lLR" sobre ssh y mide el tiempo que lleva transmitir el resultado. "time ssh remotehost 'cd / dest && ls -lLR'> / tmp / list". Asegúrese de que la lista / tmp / se cree en el host local.
TomOnTime
Sí, la red es lenta. Es una pena.
guettli
Que lento Si usa "scp" para copiar un archivo de 100M, ¿cuánto tarda? Además, ¿cuál es el resultado de "time ssh remotehost 'cd / dest && ls -lLR'> / tmp / list"?
TomOnTime
2

No, eso no es posible con rsync y sería bastante ineficiente en otro aspecto:

Normalmente, rsyncsolo compara fechas de modificación de archivos y tamaños de archivos. Su enfoque lo obligaría a leer y sumar el contenido de todos los archivos dos veces (en el sistema local y remoto) para encontrar directorios modificados.

Sven
fuente
1
AFAIK rsync comprueba mtime y size. Si ambas coincidencias, el archivo no se transfiere nuevamente (al menos en la configuración predeterminada). Sería suficiente enviar el hash de las tuplas (nombre de archivo, tamaño, mtime). No hay necesidad de sumar el contenido.
guettli
Sí, tienes razón, pero de todos modos, rsyncno hace esto.
Sven
2

Para la sincronización de grandes cantidades de archivos (donde poco ha cambiado), también vale la pena configurarlo noatimeen las particiones de origen y destino. Esto ahorra tiempos de acceso de escritura al disco para cada archivo sin cambios.

Andy Beverley
fuente
Sí, la opción noatime tiene sentido. Lo usamos desde hace varios años. Supongo que se necesita una alternativa a rsync.
guettli
2

También puede probar lsyncd, que rsync solo cuando se detectan cambios en el sistema de archivos y solo en los subdirectorios modificados. Lo he estado usando para directorios con hasta dos millones de archivos en un servidor decente.

Juanga Covas
fuente