Investigamos en todo el mundo online para darte la solución a tu problema, si continúas con alguna difcultad puedes dejar la duda y te contestaremos con gusto.
Solución:
Solución 1:
Algunos puntos no relacionados:
80K son muchos archivos.
80.000 archivos en un directorio? Ningún sistema operativo o aplicación maneja muy bien esa situación de forma predeterminada. Acaba de notar este problema con rsync.
Verifique su versión de rsync
Rsync moderno 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 en 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. Realice una prueba de funcionamiento mientras observa el uso de la memoria. Linux usa 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 swap, el rendimiento será realmente malo.
Asegúrese de que –checksum no se esté utilizando
--checksum (o -c) requiere leer todos y cada uno de los bloques de cada archivo. Probablemente pueda arreglárselas con el comportamiento predeterminado de simplemente leer los tiempos de modificación (almacenados en el inodo).
Divida el trabajo en lotes pequeños.
Hay algunos proyectos como Gigasync que “recortan la carga de trabajo usando perl para recurrir al árbol de directorios, construyendo 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 se hacen 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 asumen 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 carpeta grandes ralentizan el rendimiento de E / S?
Mira el “caché de namei”
Los sistemas operativos tipo BSD tienen una caché que acelera la búsqueda de un nombre para el inodo (la caché “namei”). Hay una caché namei para cada directorio. Si es demasiado pequeña, es un obstáculo más que una optimización. Dado que rsync está haciendo un lstat () en cada archivo, se está accediendo al inodo para cada uno de los archivos 80k. Eso podría estar arruinando 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 sistema de archivos gran cantidad de archivos en un solo directorio
Quizás 5 minutos es lo mejor que puede hacer.
Considere calcular cuántos bloques de disco se están leyendo y calcule qué tan rápido debería esperar que el hardware pueda leer esa cantidad de bloques.
Quizás tus expectativas sean demasiado altas. Considere cuántos bloques de disco deben leerse para hacer un rsync sin archivos modificados: cada servidor necesitará leer el directorio y leer un inodo por archivo. Supongamos que no hay nada en caché porque, bueno, 80k archivos probablemente han agotado su caché. Digamos que son 80k bloques para mantener las matemáticas simples. Eso es aproximadamente 40 millones de datos, que deberían poder leerse en unos segundos. Sin embargo, si es necesario realizar una búsqueda de disco entre cada bloque, esto podría llevar mucho más tiempo.
Entonces necesitará leer alrededor de 80,000 bloques de disco. ¿Qué tan rápido puede hacer eso su disco duro? Teniendo en cuenta que se trata de una E / S aleatoria, no una lectura lineal larga, 5 minutos pueden ser bastante excelentes. Eso es 1 / (80000/600), o un disco leído cada 7,5 ms. ¿Es eso 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 -Llr realiza la misma cantidad de actividad en el disco pero nunca lee ningún dato de archivo (solo metadatos). El tiempo ls -Llr tarda en correr es su límite superior.
-
¿Es rsync (sin cambios de archivos) significativamente más lento que
ls -Llr? Entonces, las opciones que está utilizando para rsync se pueden mejorar. Quizás-cestá habilitado o algún otro indicador que lee más que solo directorios y metadatos (datos de inodo). -
¿Es rsync (sin cambios de archivos) casi tan rápido como
ls -Llr? Entonces ha ajustado rsync lo mejor que puede. Tienes que ajustar el sistema operativo, agregar RAM, obtener unidades más rápidas, cambiar 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 muy bien directorios tan grandes. Si los nombres de archivo son abcdefg.txt, considere almacenarlos en abdc / abcdefg.txt (observe la repetición). Esto divide los directorios en otros más 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ían una opción mucho mejor para almacenar grandes cantidades de datos.
Oye, ¿qué pasa con 5 minutos?
Por último, ¿5 minutos son realmente tan malos? Si ejecuta esta copia de seguridad una vez al día, 5 minutos no es mucho tiempo. Sí, me encanta la velocidad. Sin embargo, si 5 minutos es “suficientemente bueno” para sus clientes, entonces es suficiente 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 continúe con otros proyectos que requieran su esfuerzo.
Actualizar: Después de un poco de discusión, determinamos que el cuello de botella es la red. Voy a recomendar 2 cosas antes de rendirme :-).
- 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. Prueba rsync con y sin
-zy configure su ssh con y sin compresión. Calcula el tiempo de las 4 combinaciones para ver si alguna de ellas funciona significativamente mejor que otras. - Observe el tráfico de la red para ver si hay pausas. Si hay pausas, puede encontrar qué las está causando y optimizar allí. Si rsync siempre está enviando, entonces realmente estás en tu límite. Tus opciones son:
- una red más rápida
- algo diferente a rsync
- acerque el origen y el destino. 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 el rsync inicial.
Solucion 2:
También puede probar lsyncd, que hará rsync solo cuando se detecten 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.
Solución 3:
Creo que 80k archivos hoy no es nada extraordinario.
Mi explicación del problema radica en la forma en que rsync obras: ver aquí. Ellos dicen: Mientras se construye, cada entrada se transmite al lado receptor de una manera optimizada para la red.
Esto lleva al envío de escritura-parada-escritura-parada-escritura a través de la red, que supuestamente es inferior a preparar primero los datos completos y luego enviarlos a través de la red a toda velocidad. La secuencia de escritura-parada-escritura-parada-escritura puede requerir muchos viajes de ida y vuelta de red más, en el peor de los casos, incluso 80k viajes de ida y vuelta de red …
Consulte información sobre el manejo de paquetes TCP, el algoritmo de Nagle, etc. Esto también se corresponde con la evidencia empírica: al diseñar un sistema que procesa datos a granel, se deben utilizar técnicas de lotes y no evadir las técnicas utilizadas en sistemas en tiempo real que procesan cada artículo / registro individualmente.
hice un examen práctico con un programa de sincronización que de hecho funciona por lotes: el sincronizador local Zaloha.sh se ha ampliado recientemente para permitir la copia de seguridad remota: Zaloha2.sh. Consíguelo en Fitus / Zaloha.sh, la nueva versión está bajo la Zaloha2.sh enlace cerca de los “tres gatos”.
El programa funciona ejecutando find en los directorios para obtener archivos CSV. los find en el directorio remoto se ejecuta en un ssh sesión y después finaliza, el archivo CSV se descarga al sistema local por scp. los find en el directorio local se ejecuta localmente. La comparación de los dos archivos CSV se realiza localmente por GNU sort y mawk.
He elegido uno de mis directorios para que coincida más con 80k archivos (de hecho, son casi 90k archivos y 3k directorios). El hardware utilizado durante la prueba no es nada especial o “de vanguardia”: una computadora portátil de ocho años con Linux y una PC de escritorio de aproximadamente la misma edad con Linux como host de respaldo remoto. El enlace entre ellos es una red Wi-Fi doméstica sencilla.
El portátil tiene sus datos en un disco duro externo conectado por USB (!), La PC de escritorio tiene sus datos en un disco duro interno.
Los datos están en estado sincronizado (la misma condición que la suya) excepto por un archivo no sincronizado (para probar que Zaloha2.sh de hecho lo detecta).
Resultados de la prueba práctica:
los find el escaneo del disco duro externo conectado por USB tomó 1 minuto y 7 segundos. los find el escaneo del disco duro interno tomó 14 segundos. los scp-transferencia de archivos CSV a través de Wi-Fi y su sort y mawk
el procesamiento tomó 34 segundos.
En general: 1 minuto y 56 segundos.
De hecho, se detectó el único archivo diferente.
Curiosamente, cuando se vuelve a ejecutar toda la prueba, ambos finds terminó casi de inmediato. Supongo que esto se debe al almacenamiento en caché de los datos del directorio en los núcleos de Linux.
La segunda prueba duró apenas 35 segundos …
Espero que esto ayude.
Solución 4:
No, eso no es posible con rsync y sería bastante ineficiente en otro aspecto:
Normalmente, rsync solo 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 archivos dos veces (en el sistema local y remoto) para encontrar los directorios modificados.
Solución 5:
Para la sincronización de una gran cantidad de archivos (donde poco ha cambiado), también vale la pena configurar noatime en las particiones de origen y destino. Esto ahorra tiempos de acceso de escritura al disco para cada expediente.
Si para ti ha sido de provecho nuestro artículo, agradeceríamos que lo compartas con otros programadores así nos ayudas a dar difusión a nuestro contenido.