Alcuni punti non correlati:
80K sono molti file.
80.000 file in una directory? Nessun sistema operativo o app gestisce questa situazione molto bene per impostazione predefinita. Ti capita di notare questo problema con rsync.
Controlla la tua versione di rsync
Modern rsync gestisce le grandi directory molto meglio che in passato. Assicurati di utilizzare l'ultima versione.
Persino la vecchia rsync gestisce directory di grandi dimensioni abbastanza bene su collegamenti ad alta latenza ... ma i file 80k non sono grandi ... è enorme!
Detto questo, l'utilizzo della memoria di rsync è direttamente proporzionale al numero di file in un albero. Le directory di grandi dimensioni richiedono una grande quantità di RAM. La lentezza può essere dovuta alla mancanza di RAM su entrambi i lati. Esegui un test mentre guardi l'utilizzo della memoria. Linux utilizza qualsiasi RAM rimasta come cache del disco, quindi se si sta esaurendo la RAM, c'è meno cache sul disco. Se esaurisci la RAM e il sistema inizia a utilizzare lo scambio, le prestazioni saranno davvero pessime.
Assicurarsi che --checksum non sia utilizzato
--checksum(o -c) richiede la lettura di ogni singolo blocco di ogni file. Probabilmente è possibile cavarsela con il comportamento predefinito della sola lettura dei tempi di modifica (memorizzati nell'inode).
Dividi il lavoro in piccoli lotti.
Ci sono alcuni progetti come Gigasync che "ridurrà il carico di lavoro usando perl per richiamare l'albero delle directory, costruendo piccoli elenchi di file da trasferire con rsync".
La scansione della directory extra sarà una grande quantità di overhead, ma forse sarà una vincita netta.
Le impostazioni predefinite del sistema operativo non sono fatte per questa situazione.
Se stai usando Linux / FreeBSD / etc con tutte le impostazioni predefinite, le prestazioni saranno terribili per tutte le tue applicazioni. Le impostazioni predefinite presuppongono directory più piccole in modo da non sprecare RAM in cache di grandi dimensioni.
Ottimizza il tuo filesystem per gestire meglio directory di grandi dimensioni : le cartelle di grandi dimensioni rallentano le prestazioni di I / O?
Guarda la "cache dei nomi"
I sistemi operativi simili a BSD hanno una cache che accelera la ricerca di un nome nell'inode (la cache "namei"). C'è una cache namei per ogni directory. Se è troppo piccola, è un ostacolo più che un'ottimizzazione. Poiché rsync sta eseguendo un file lstat () su ciascun file, l'accesso all'inode è possibile per ciascuno dei file 80k. Ciò potrebbe far esplodere la cache. Ricercare come ottimizzare le prestazioni della directory dei file sul proprio sistema.
Prendi in considerazione un file system diverso
XFS è stato progettato per gestire directory più grandi. Vedi File system per un gran numero di file in una singola directory
Forse 5 minuti è il massimo che puoi fare.
Prendi in considerazione il calcolo del numero di blocchi del disco che stai leggendo e calcola quanto velocemente dovresti aspettarti che l'hardware sia in grado di leggere quel numero di blocchi.
Forse le tue aspettative sono troppo alte. Considera quanti blocchi di dischi devono essere letti per eseguire una risincronizzazione senza file modificati: ogni server dovrà leggere la directory e leggere un inode per file. Supponiamo che nulla sia memorizzato nella cache perché, beh, i file 80k probabilmente hanno rovinato la cache. Diciamo che sono 80k i blocchi per semplificare la matematica. Sono circa 40 milioni di dati, che dovrebbero essere leggibili in pochi secondi. Tuttavia, se è necessario cercare un disco tra ciascun blocco, ciò potrebbe richiedere molto più tempo.
Quindi dovrai leggere circa 80.000 blocchi di dischi. Quanto velocemente può farlo il tuo disco rigido? Considerando che si tratta di I / O casuali, non di una lettura lineare lunga, 5 minuti potrebbero essere piuttosto eccellenti. Quello è 1 / (80000/600), o un disco letto ogni 7,5 ms. È veloce o lento per il tuo disco rigido? Dipende dal modello.
Punto di riferimento contro qualcosa di simile
Un altro modo di pensarci è questo. Se nessun file è stato modificato, ls -Llrsvolge la stessa quantità di attività del disco ma non legge mai i dati dei file (solo metadati). Il tempo ls -Llrnecessario per correre è il limite superiore.
Rsync (senza i file modificati) è significativamente più lento di ls -Llr? Quindi le opzioni che stai usando per rsync possono essere migliorate. Forse -cè abilitato o qualche altro flag che legge più di semplici directory e metadati (dati inode).
Rsync (senza i file modificati) è quasi veloce ls -Llr? Quindi hai sintonizzato rsync nel miglior modo possibile. Devi ottimizzare il sistema operativo, aggiungere RAM, ottenere unità più veloci, cambiare file system, ecc.
Parla con i tuoi sviluppatori
I file 80k sono solo cattivi design. Pochissimi file system e strumenti di sistema gestiscono molto bene directory così grandi. Se i nomi dei file sono abcdefg.txt, considerare di memorizzarli in abdc / abcdefg.txt (notare la ripetizione). Questo suddivide le directory in più piccole, ma non richiede una grande modifica al codice.
Inoltre .... considera l'utilizzo di un database. Se hai 80k file in una directory, forse i tuoi sviluppatori stanno lavorando sul fatto che quello che vogliono veramente è un database. MariaDB o MySQL o PostgreSQL sarebbero un'opzione molto migliore per l'archiviazione di grandi quantità di dati.
Ehi, cosa c'è che non va in 5 minuti?
Infine, 5 minuti sono davvero così male? Se si esegue questo backup una volta al giorno, 5 minuti non sono molto tempo. Sì, adoro la velocità. Tuttavia, se 5 minuti sono "abbastanza buoni" per i tuoi clienti, allora sono abbastanza buoni per te. Se non hai uno SLA scritto, che ne dici di una discussione informale con i tuoi utenti per scoprire quanto velocemente si aspettano i backup.
Presumo che tu non abbia posto questa domanda se non fosse necessario migliorare le prestazioni. Tuttavia, se i tuoi clienti sono soddisfatti di 5 minuti, dichiara la vittoria e passa ad altri progetti che richiedono i tuoi sforzi.
Aggiornamento: dopo alcune discussioni abbiamo stabilito che il collo di bottiglia è la rete. Consiglierò 2 cose prima di arrendermi :-).
- Prova a spremere più larghezza di banda dal tubo con la compressione. Tuttavia, la compressione richiede più CPU, quindi se la tua CPU è sovraccarica, le prestazioni potrebbero peggiorare. Prova rsync con e senza
-ze configura il tuo ssh con e senza compressione. Tempo tutte e 4 le combinazioni per vedere se qualcuno di loro ha prestazioni significativamente migliori rispetto ad altri.
- Guarda il traffico di rete per vedere se ci sono pause. Se ci sono pause, puoi trovare ciò che le sta causando e ottimizzare lì. Se rsync invia sempre, allora sei davvero al limite. Le tue scelte sono:
- una rete più veloce
- qualcosa di diverso da rsync
- avvicinare la fonte e la destinazione. Se non riesci a farlo, puoi risincronizzare con un computer locale e poi risincronizzare con la destinazione reale? Potrebbero esserci dei benefici nel fare questo se il sistema deve essere spento durante la rsync iniziale.