Come eliminare milioni di file senza disturbare il server

Soluzione 1:

Crea uno script bash come questo:

#!/bin/bash
rm -- "$*"
sleep 0.5

Salvalo con il nome deleter.sh Per esempio. Esegui chmod u+x deleter.sh per renderlo eseguibile.

Questo script elimina tutti i file che gli vengono passati come argomenti, quindi rimane inattivo per 0,5 secondi.

Poi puoi correre

find cache.bak -print0 | xargs -0 -n 5 deleter.sh

Questo comando recupera un elenco di tutti i file in cache.bak e passa i cinque nomi di file alla volta allo script di eliminazione.

Pertanto, puoi regolare quanti file vengono eliminati alla volta e quanto tempo intercorre tra ogni operazione di eliminazione.

Soluzione 2:

Dovresti considerare di salvare la tua cache su un filesystem separato che puoi montare/smontare come qualcuno ha affermato nei commenti. Fino a quando non lo fai, puoi usare questa riga /usr/bin/find /path/to/files/ -type f -print0 -exec sleep 0.2 \; -exec echo \; -delete supponendo che il tuo find binario si trovi sotto /usr/bin e tu voglia vedere i progressi sullo schermo. Regola la sospensione di conseguenza, in modo da non sovraccaricare il tuo HDD.

Soluzione 3:

Potresti provare ionice su uno script che utilizza l'output di un comando find. Qualcosa di simile al seguente:

ionice -c3 $(
for file in find cache.bak -type f; do
    rm $file
done
for dir in find cache.bak -depthe -type d -empty; do
    rmdir $dir
done
)

A seconda del filesystem, ogni eliminazione di file può comportare la riscrittura dell'intera directory. Per le directory di grandi dimensioni che possono essere un bel successo. Sono necessari ulteriori aggiornamenti per la tabella degli inode e possibilmente un elenco di spazi liberi.

Se il file system ha un journal, le modifiche vengono scritte nel journal; applicato; e rimosso dal diario. Ciò aumenta i requisiti di I/O per l'attività intensiva di scrittura.

Potresti voler usare un filesystem senza un journal per la cache.

Invece di ionice, puoi usare un comando sleep per limitare le azioni. Funzionerà anche se ionice no, ma ci vorrà molto tempo per eliminare tutti i tuoi file.

Soluzione 4:

Ho ricevuto molte risposte/commenti utili qui, che vorrei concludere oltre a mostrare anche la mia soluzione.

1. Sì, il modo migliore per prevenire una cosa del genere è mantenere la directory della cache su un filesystem separato. Nuking/formattazione rapida di un file system richiede sempre pochi secondi (forse minuti) al massimo, indipendentemente dal numero di file/directory presenti.

2. Il ionice / nice solutions non ha fatto nulla, perché il processo di eliminazione in realtà non ha causato quasi nessun I/O. Ciò che ha causato l'I/O è stato, credo, il riempimento delle code/buffer a livello di kernel/filesystem quando i file sono stati eliminati troppo rapidamente dal processo di eliminazione.

3. Il modo in cui l'ho risolto è simile alla soluzione di Tero Kilkanen, ma non richiedeva di chiamare uno script di shell. Ho usato il --bwlimit integrato di rsync passare per limitare la velocità di eliminazione.

Il comando completo era:

mkdir empty_dir
rsync -v -a --delete --bwlimit=1 empty_dir/ cache.bak/

Ora bwlimit specifica la larghezza di banda in kiloby, che in questo caso si applicava al nome file o al percorso dei file. Impostandolo su 1 KBps, eliminava circa 100.000 file all'ora o 27 file al secondo. I file avevano percorsi relativi come cache.bak/e/c1/db98339573acc5c76bdac4a601f9ec1e , che è lungo 47 caratteri, quindi darebbe 1000/47 ~=21 file al secondo, quindi un po' simile alla mia ipotesi di 100.000 file all'ora.

Ora perché --bwlimit=1 ? Ho provato vari valori:

• 10000, 1000, 100 -> il sistema rallenta come prima
• 10 -> il sistema funziona abbastanza bene per un po', ma produce rallentamenti parziali una volta al minuto circa. Tempi di risposta HTTP ancora <1 sec.
• 1 -> nessun rallentamento del sistema. Non ho fretta e in questo modo è possibile eliminare 2 milioni di file in <1 giorno, quindi lo scelgo.

Mi piace la semplicità del metodo integrato di rsync, ma questa soluzione dipende dalla lunghezza del percorso relativo. Non è un grosso problema poiché la maggior parte delle persone troverebbe il giusto valore tramite tentativi ed errori.