☰

La transferencia Rsync a través de SSH es muy lenta

tag-icon • tag-icon backup rsync
La transferencia Rsync a través de SSH es muy lenta

Estoy haciendo una copia de seguridad remota de mi sitio web. El catálogo completo tiene aproximadamente 70 GB con aproximadamente 5.000.000 de archivos en total. Aquí está el comando que ejecuto en mi servidor de respaldo:

rsync -ah -e ssh --delete --link-dest=/backups/2013.09.06 [email protected]:/var/www/backups/2013.09.07

El proceso dura más de 48 horas y simplemente se bloquea.

Ejecuté strace -pel proceso rsync en el cliente (servidor web donde se encuentra el sitio web) y vi que el proceso se detiene periódicamente cuando selectel comando termina = 0 (Timeout)después de un tiempo y luego continúa.

open("mysite/files/1694201", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=10083, ...}) = 0
read(3, "\r\n\320\224\320\265\321\201\321\217\321\202\321\214 \320\273\320\265\321\202, \321\210\320\265\321\201\321\202\321"..., 10083) = 10083
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999998})
write(1, "\374\17\0\7", 4)              = 4
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999999})
write(1, "\320\260\320\262\320\260\320\271\321\202\320\265...\320\232\320\270\320\264\320\260\320\271\321\202\320\265 \320\274"..., 4092) = 4092
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999999})
write(1, "\374\17\0\7", 4)              = 4
select(2, NULL, [1], [1], {60, 0})      = 0 (Timeout)

El proceso se cuelga en la última línea durante aproximadamente un minuto.

¿Por qué puede estar pasando esto? ¿Por qué el proceso tarda tanto y nunca llega al final? ¿Qué podrían 0 (Timeout)significar los que están en strace?

Ambos servidores ejecutan rsync 3.0.9, IO no está sobrecargado.

Respuesta1

¿Qué podrían significar esos 0 (Tiempo de espera) en strace?

Vaya a leer sobre el quinto parámetro.pasado para seleccionar.

Claramente, rsync (por sí solo) no es apropiado para el método que ha elegido para realizar la copia de seguridad de los archivos. Tiene que generar un hash para cada uno de los 5 millones de archivos y enviarlo a través de la red solo para ver si algo ha cambiado.

Si fuera yo, lo incluiría en un script que se ejecuta en el servidor de origen que

  1. Comprueba la hora (tstart) en la que se inició la sincronización exitosa anterior

  2. Encuentra todos los archivos en la fuente que tienen un mtime > tstart

  3. rsync esos archivos modificados al servidor de respaldo

p.ej

#!/bin/bash

touch newrun
find /var/www -newer lastrun -exec rsync ....
rm -f lastrun
mv newrun lastrun

Respuesta2

¿Estás seguro de que tienes 5 mil millones de archivos?

Prefiero tgz y rsync que tgz, ya que la comparación inicial de src a dst tomaría una eternidad si tienes discos duros algo "normales", sin SAN o SSD de alta velocidad.

¿Dónde está tu proceso es lento? durante la transferencia de archivos o durante src<->dst inicial - ¿verificar? (enviando lista de archivos incremental...)

Si es posible, comprobaría IOWAIT en ambos extremos. y, si las máquinas tienen md-raid, cat /proc/mdstatus. Un rendimiento de io muy malo puede ser el resultado de una incursión de reconstrucción (pero es muy poco probable).

y realicé una transferencia con un solo archivo grande --progressactivado durante la transferencia rsync para verificar la velocidad de la red.

sugerencias de depuración(debe probar cada posible cuello de botella, aunque sea solo para asegurarse: este NO es el problema)

  • prueba rsync con -avzh --progress --stats
  • rendimiento io localmente
  • rendimiento de la red
  • hd/raid-status (SMART), comprobar si hay hardware defectuoso

información relacionada