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.