Solución 1:
El conteo de archivos y la sobrecarga de cifrado SSH son probablemente las mayores barreras. No verá la velocidad del cable en una transferencia como esta.
Las opciones para mejorar incluyen:
- Usar rsync+SSH con un algoritmo de cifrado menos costoso (por ejemplo,
-e "ssh -c arcfour") - Eliminar el cifrado por completo sobre el transporte SSH con algo como HPN-SSH.
- Transferencias basadas en bloques. Instantáneas,
dd, envío/recepción de instantáneas ZFS, etc. - Si se trata de una transferencia única o poco frecuente, use
tar, netcat (nc), mbuffer o alguna combinación. - Comprueba tu CentOS
tuned-admconfiguración. - Eliminar el atime de los montajes de su sistema de archivos. Examinando otras opciones de montaje del sistema de archivos.
- Búferes de envío/recepción de NIC.
- Afinando tu
rsyncdominio. Tendría-W, la opción de archivos completos tiene sentido aquí? ¿Está habilitada la compresión? - Optimice su subsistema de almacenamiento para el tipo de transferencias (SSD, conteo de ejes, caché del controlador RAID).
Solución 2:
Como probablemente sepa, copiar muchos archivos pequeños (por ejemplo, buzones de correo que usan el formato MailDir o similar) definitivamente no es la mejor opción para aprovechar las interfaces de alto ancho de banda. SSH probablemente tampoco sea el mejor protocolo de transporte para eso. Intentaría usar tar para crear un tarball en el host de origen antes de enviarlo a su host secundario.
tar c /var/mail | ssh [email protected] 'tar x -C /var/backups'
Si necesita una copia de seguridad incremental, puede probar el -g opciones de tar. Si aún necesita maximizar el rendimiento, intente usar netcat en lugar de ssh.