Soluzione 1:
Il conteggio dei file e l'overhead della crittografia SSH sono probabilmente i maggiori ostacoli. Non vedrai wire-speed su un trasferimento come questo.
Le opzioni da migliorare includono:
- Uso di rsync+SSH con un algoritmo di crittografia meno costoso (ad es.
-e "ssh -c arcfour") - Eliminare completamente la crittografia sul trasporto SSH con qualcosa come HPN-SSH.
- Trasferimenti basati su blocchi. Istantanee,
dd, invio/ricezione snapshot ZFS, ecc. - Se si tratta di un trasferimento una tantum o poco frequente, utilizzare
tar, netcat (nc), mbuffer o qualche combinazione. - Controlla il tuo CentOS
tuned-admimpostazioni. - Rimuovere l'atime dai montaggi del filesystem. Esame delle altre opzioni di montaggio del filesystem.
- Buffer di invio/ricezione NIC.
- Ottimizza il tuo
rsynccomando. Sarebbe-W, l'opzione whole-files ha senso qui? La compressione è abilitata? - Ottimizza il tuo sottosistema di archiviazione per il tipo di trasferimenti (SSD, numero di assi, cache del controller RAID.)
Soluzione 2:
Come probabilmente saprai, copiare molti piccoli file (ad esempio cassette postali che utilizzano il formato MailDir o simili) non è sicuramente l'opzione migliore per sfruttare le interfacce a larghezza di banda elevata. SSH probabilmente non è nemmeno il miglior protocollo di trasporto per questo. Proverei a utilizzare tar per creare un tarball sull'host di origine prima di inviarlo all'host secondario.
tar c /var/mail | ssh [email protected] 'tar x -C /var/backups'
Se hai bisogno di un backup incrementale potresti provare il -g opzioni di tar.Se hai ancora bisogno di massimizzare il throughput, prova a usare netcat invece di ssh.