rm su una directory con milioni di file

Sfondo: server fisico, circa due anni, unità SATA 7200-RPM connesse a una scheda RAID 3Ware, no3 tempo montato su ext3 FS e dati = ordinati, non sotto carico, kernel 2.6.18-92.1.22.el5, uptime 545 giorni . La directory non contiene alcuna sottodirectory, solo milioni di file piccoli (~ 100 byte), con alcuni più grandi (pochi KB).

Abbiamo un server che è diventato un po 'cuculo nel corso degli ultimi mesi, ma l'abbiamo notato solo l'altro giorno quando ha iniziato a non essere in grado di scrivere in una directory perché conteneva troppi file. In particolare, ha iniziato a lanciare questo errore in / var / log / messages:

ext3_dx_add_entry: Directory index full!

Il disco in questione ha molti inode rimanenti:

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda3            60719104 3465660 57253444    6% /

Quindi suppongo che ciò significhi che abbiamo raggiunto il limite di quante voci possono essere nel file di directory stesso. Non ho idea di quanti file sarebbero, ma non può essere più, come puoi vedere, di circa tre milioni. Non che va bene, intendiamoci! Ma questa è la prima parte della mia domanda: che cos'è esattamente quel limite superiore? È sintonizzabile? Prima di sgridato-voglio sintonizzare giù ; questa enorme directory ha causato tutti i tipi di problemi.

Ad ogni modo, abbiamo rintracciato il problema nel codice che stava generando tutti quei file e lo abbiamo corretto. Ora sono bloccato con l'eliminazione della directory.

Alcune opzioni qui:

1. rm -rf (dir)

   L'ho provato prima io. Ho rinunciato e l'ho ucciso dopo che era corso per un giorno e mezzo senza alcun impatto evidente.

2. unlink (2) nella directory: vale sicuramente la pena considerare, ma la domanda è se sarebbe più veloce eliminare i file all'interno della directory tramite fsck che eliminarli tramite unlink (2). Cioè, in un modo o nell'altro, devo contrassegnare quegli inode come inutilizzati. Ciò presuppone, ovviamente, che posso dire a fsck di non rilasciare le voci nei file in / lost + found; altrimenti, ho appena spostato il mio problema. Oltre a tutte le altre preoccupazioni, dopo aver letto un po 'di più su questo, si scopre che probabilmente dovrei chiamare alcune funzioni interne di FS, poiché nessuna delle varianti unlink (2) che riesco a trovare mi permetterebbe di cancellare solo allegramente una directory con le voci al suo interno. Pooh.
3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

   Questa è in realtà la versione abbreviata; quello vero che sto correndo, che aggiunge solo alcuni rapporti sui progressi e un punto fermo quando finiamo i file da eliminare, è:

   esportazione i = 0;
   tempo (while [true]; do
     ls -Uf | capo -n 3 | grep -qF '.png' || rompere;
     ls -Uf | head -n 10000 | xargs rm -f 2> / dev / null;
     esporta i = $ (($ i + 10000));
     echo "$ i ...";
   fatto )

   Questo sembra funzionare piuttosto bene. Mentre scrivo, negli ultimi trenta minuti circa ha eliminato 260.000 file.

1. Come accennato in precedenza, è possibile regolare il limite di voci per directory?
2. Perché ci sono voluti "7m9.561s reali / utente 0m0.001s / sys 0m0.001s" per eliminare un singolo file che era il primo nell'elenco restituito ls -Ue ci sono voluti forse dieci minuti per eliminare le prime 10.000 voci con il comando in # 3, ma ora si trascina abbastanza felicemente? Del resto, ha eliminato 260.000 in circa trenta minuti, ma ora sono necessari altri quindici minuti per eliminarne altri 60.000. Perché le enormi oscillazioni di velocità?
3. C'è un modo migliore per fare questo genere di cose? Non archiviare milioni di file in una directory; So che è sciocco e non sarebbe successo sul mio orologio. Cercare su Google il problema e guardare attraverso SF e SO offre molte varianti findche non saranno significativamente più veloci del mio approccio per diverse ragioni evidenti. Ma l'idea di eliminare-via-fsck ha delle gambe? O qualcos'altro interamente? Sono ansioso di sentire il pensiero fuori dagli schemi (o dentro-non-ben-conosciuto-scatola).

Output dello script finale !:

2970000...
2980000...
2990000...
3000000...
3010000...

real    253m59.331s
user    0m6.061s
sys     5m4.019s

Quindi, tre milioni di file eliminati in poco più di quattro ore.

L' data=writebackopzione mount merita di essere provata, al fine di impedire l'inserimento nel journal del file system. Questo dovrebbe essere fatto solo durante il tempo di eliminazione, tuttavia esiste un rischio se il server viene arrestato o riavviato durante l'operazione di eliminazione.

Secondo questa pagina ,

Alcune applicazioni mostrano un miglioramento della velocità molto significativo quando viene utilizzato. Ad esempio, i miglioramenti della velocità possono essere visti (...) quando le applicazioni creano ed eliminano grandi volumi di piccoli file.

L'opzione è impostata in fstabo durante l'operazione di montaggio, sostituendo data=orderedcon data=writeback. Il file system contenente i file da eliminare deve essere rimontato.

Mentre una delle principali cause di questo problema è la prestazione ext3 con milioni di file, la causa principale di questo problema è diversa.

Quando è necessario elencare una directory, readdir () viene chiamato nella directory che produce un elenco di file. readdir è una chiamata posix, ma la vera chiamata di sistema Linux utilizzata qui si chiama 'getdents'. Getdents elenca le voci della directory riempiendo un buffer di voci.

Il problema è principalmente dovuto al fatto che readdir () utilizza una dimensione del buffer fissa di 32 KB per recuperare i file. Man mano che una directory diventa sempre più grande (la dimensione aumenta man mano che vengono aggiunti i file) ext3 diventa sempre più lento nel recuperare le voci e la dimensione aggiuntiva del buffer di 32 KB di readdir è sufficiente per includere solo una frazione delle voci nella directory. Questo fa sì che readdir si ripeti ripetutamente e invochi ripetutamente la costosa chiamata di sistema.

Ad esempio, in una directory di test che ho creato con oltre 2,6 milioni di file all'interno, l'esecuzione di "ls -1 | wc-l" mostra un output di grandi dimensioni di molte chiamate di sistema getdent.

$ strace ls -1 | wc -l
brk(0x4949000)                          = 0x4949000
getdents(3, /* 1025 entries */, 32768)  = 32752
getdents(3, /* 1024 entries */, 32768)  = 32752
getdents(3, /* 1025 entries */, 32768)  = 32760
getdents(3, /* 1025 entries */, 32768)  = 32768
brk(0)                                  = 0x4949000
brk(0x496a000)                          = 0x496a000
getdents(3, /* 1024 entries */, 32768)  = 32752
getdents(3, /* 1026 entries */, 32768)  = 32760
...

Inoltre, il tempo trascorso in questa directory è stato significativo.

$ time ls -1 | wc -l
2616044

real    0m20.609s
user    0m16.241s
sys 0m3.639s

Il metodo per rendere questo un processo più efficiente consiste nel chiamare manualmente getdents con un buffer molto più grande. Questo migliora significativamente le prestazioni.

Ora, non dovresti chiamare manualmente getdents, quindi non esiste alcuna interfaccia per usarlo normalmente (controlla la pagina man per vedere getdents!), Tuttavia puoi chiamarlo manualmente e rendere la tua chiamata di sistema più efficiente.

Ciò riduce drasticamente il tempo necessario per recuperare questi file. Ho scritto un programma che fa questo.

/* I can be compiled with the command "gcc -o dentls dentls.c" */

#define _GNU_SOURCE

#include <dirent.h>     /* Defines DT_* constants */
#include <err.h>
#include <fcntl.h>
#include <getopt.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>

struct linux_dirent {
        long           d_ino;
        off_t          d_off;
        unsigned short d_reclen;
        char           d_name[256];
        char           d_type;
};

static int delete = 0;
char *path = NULL;

static void parse_config(
        int argc,
        char **argv)
{
    int option_idx = 0;
    static struct option loptions[] = {
      { "delete", no_argument, &delete, 1 },
      { "help", no_argument, NULL, 'h' },
      { 0, 0, 0, 0 }
    };

    while (1) {
        int c = getopt_long(argc, argv, "h", loptions, &option_idx);
        if (c < 0)
            break;

        switch(c) {
          case 0: {
              break;
          }

          case 'h': {
              printf("Usage: %s [--delete] DIRECTORY\n"
                     "List/Delete files in DIRECTORY.\n"
                     "Example %s --delete /var/spool/postfix/deferred\n",
                     argv[0], argv[0]);
              exit(0);                      
              break;
          }

          default:
          break;
        }
    }

    if (optind >= argc)
      errx(EXIT_FAILURE, "Must supply a valid directory\n");

    path = argv[optind];
}

int main(
    int argc,
    char** argv)
{

    parse_config(argc, argv);

    int totalfiles = 0;
    int dirfd = -1;
    int offset = 0;
    int bufcount = 0;
    void *buffer = NULL;
    char *d_type;
    struct linux_dirent *dent = NULL;
    struct stat dstat;

    /* Standard sanity checking stuff */
    if (access(path, R_OK) < 0) 
        err(EXIT_FAILURE, "Could not access directory");

    if (lstat(path, &dstat) < 0) 
        err(EXIT_FAILURE, "Unable to lstat path");

    if (!S_ISDIR(dstat.st_mode))
        errx(EXIT_FAILURE, "The path %s is not a directory.\n", path);

    /* Allocate a buffer of equal size to the directory to store dents */
    if ((buffer = calloc(dstat.st_size*3, 1)) == NULL)
        err(EXIT_FAILURE, "Buffer allocation failure");

    /* Open the directory */
    if ((dirfd = open(path, O_RDONLY)) < 0) 
        err(EXIT_FAILURE, "Open error");

    /* Switch directories */
    fchdir(dirfd);

    if (delete) {
        printf("Deleting files in ");
        for (int i=5; i > 0; i--) {
            printf("%u. . . ", i);
            fflush(stdout);
            sleep(1);
        }
        printf("\n");
    }

    while (bufcount = syscall(SYS_getdents, dirfd, buffer, dstat.st_size*3)) {
        offset = 0;
        dent = buffer;
        while (offset < bufcount) {
            /* Don't print thisdir and parent dir */
            if (!((strcmp(".",dent->d_name) == 0) || (strcmp("..",dent->d_name) == 0))) {
                d_type = (char *)dent + dent->d_reclen-1;
                /* Only print files */
                if (*d_type == DT_REG) {
                    printf ("%s\n", dent->d_name);
                    if (delete) {
                        if (unlink(dent->d_name) < 0)
                            warn("Cannot delete file \"%s\"", dent->d_name);
                    }
                    totalfiles++;
                }
            }
            offset += dent->d_reclen;
            dent = buffer + offset;
        }
    }
    fprintf(stderr, "Total files: %d\n", totalfiles);
    close(dirfd);
    free(buffer);

    exit(0);
}

Mentre questo non combatte il problema fondamentale sottostante (molti file, in un filesystem che funziona male). È probabile che sia molto, molto più veloce di molte delle alternative pubblicate.

Come previsto, si dovrebbe rimuovere la directory interessata e rifarla dopo. Le directory aumentano sempre di dimensioni e possono rimanere scarsamente performanti anche con alcuni file all'interno a causa delle dimensioni della directory.

Modifica: ho ripulito un bel po '. Aggiunta un'opzione per permetterti di eliminare dalla riga di comando in fase di esecuzione e rimosso un sacco di roba da treewalk che, onestamente, guardando indietro era discutibile nella migliore delle ipotesi. Inoltre è stato dimostrato che produce il danneggiamento della memoria.

Ora puoi farlo dentls --delete /my/path

Nuovi risultati Basato su una directory con 1,82 milioni di file.

## Ideal ls Uncached
$ time ls -u1 data >/dev/null

real    0m44.948s
user    0m1.737s
sys 0m22.000s

## Ideal ls Cached
$ time ls -u1 data >/dev/null

real    0m46.012s
user    0m1.746s
sys 0m21.805s


### dentls uncached
$ time ./dentls data >/dev/null
Total files: 1819292

real    0m1.608s
user    0m0.059s
sys 0m0.791s

## dentls cached
$ time ./dentls data >/dev/null
Total files: 1819292

real    0m0.771s
user    0m0.057s
sys 0m0.711s

È stato un po 'sorpreso che funzioni ancora così bene!

Sarebbe possibile eseguire il backup di tutti gli altri file da questo file system in un percorso di archiviazione temporaneo, riformattare la partizione e quindi ripristinare i file?

In ext3 non esiste un limite per file di directory solo per il limite dell'inode del filesystem (penso che ci sia un limite al numero di sottodirectory).

Potresti avere ancora problemi dopo aver rimosso i file.

Quando una directory ha milioni di file, la voce della directory stessa diventa molto grande. La voce della directory deve essere scansionata per ogni operazione di rimozione e ciò richiede diversi periodi di tempo per ogni file, a seconda di dove si trova la sua voce. Sfortunatamente anche dopo che tutti i file sono stati rimossi la voce della directory mantiene le sue dimensioni. Quindi ulteriori operazioni che richiedono la scansione della voce della directory impiegheranno ancora molto tempo anche se la directory è vuota. L'unico modo per risolvere il problema è rinominare la directory, crearne una nuova con il vecchio nome e trasferire tutti i file rimanenti in quella nuova. Quindi eliminare quello rinominato.

Non l'ho confrontato, ma questo ragazzo ha fatto :

rsync -a --delete ./emptyDirectoty/ ./hugeDirectory/

find semplicemente non ha funzionato per me, anche dopo aver modificato i parametri di ext3 fs come suggerito dagli utenti sopra. Consumato troppa memoria. Questo script PHP ha funzionato: un utilizzo della CPU veloce e insignificante, un utilizzo insignificante della memoria:

<?php 
$dir = '/directory/in/question';
$dh = opendir($dir)) { 
while (($file = readdir($dh)) !== false) { 
    unlink($dir . '/' . $file); 
} 
closedir($dh); 
?>

Ho pubblicato una segnalazione di bug relativa a questo problema con find: http://savannah.gnu.org/bugs/?31961

Di recente ho riscontrato un problema simile e non sono riuscito a far funzionare il data=writebacksuggerimento di ring0 (probabilmente a causa del fatto che i file si trovano sulla mia partizione principale). Durante la ricerca di soluzioni alternative mi sono imbattuto in questo:

tune2fs -O ^has_journal <device>

Ciò disattiverà completamente il journaling, indipendentemente datadall'opzione assegnata mount. L'ho combinato con noatimeil volume dir_indeximpostato e sembrava funzionare abbastanza bene. L'eliminazione in realtà è terminata senza che io abbia bisogno di ucciderla, il mio sistema è rimasto reattivo e ora è di nuovo attivo e funzionante (con l'inserimento nel journal) senza problemi.

Assicurati di fare:

mount -o remount,rw,noatime,nodiratime /mountpoint

che dovrebbe accelerare un po 'anche le cose.

È un comando molto lento. Provare:

find /dir_to_delete ! -iname "*.png" -type f -delete

È dir_indeximpostato per il filesystem? ( tune2fs -l | grep dir_index) In caso contrario, abilitalo. Di solito è acceso per il nuovo RHEL.

Un paio di anni fa, ho trovato una directory con 16 milioni di file XML nel /filesystem. A causa della critica del server, abbiamo usato il seguente comando che ha impiegato circa 30 ore per terminare:

perl -e 'for(<*>){((stat)[9]<(unlink))}'

Era un vecchio hdd a 7200 rpm e, nonostante il collo di bottiglia di IO e i picchi di CPU, il vecchio server web ha continuato il suo servizio.

La mia opzione preferita è l'approccio newfs, già suggerito. Il problema di base è, come già notato, la scansione lineare per gestire la cancellazione è problematica.

rm -rfdovrebbe essere quasi ottimale per un filesystem locale (NFS sarebbe diverso). Ma a milioni di file, 36 byte per nome file e 4 per inode (un'ipotesi, non verificando il valore per ext3), sono 40 * milioni, da conservare nella RAM solo per la directory.

A indovinare, stai distruggendo la memoria cache dei metadati del filesystem in Linux, in modo che i blocchi per una pagina del file di directory vengano espulsi mentre stai ancora usando un'altra parte, solo per colpire di nuovo quella pagina della cache quando la prossima il file è cancellato. L'ottimizzazione delle prestazioni di Linux non è la mia area, ma / proc / sys / {vm, fs} / probabilmente contiene qualcosa di rilevante.

Se puoi permetterti i tempi di inattività, potresti considerare di attivare la funzione dir_index. Cambia l'indice di directory da lineare a qualcosa di molto più ottimale per la cancellazione in grandi directory (hash con b-tree). tune2fs -O dir_index ...seguito da e2fsck -Davrebbe funzionato. Tuttavia, anche se sono sicuro che ciò possa aiutare prima che ci siano problemi, non so come si comporta la conversione (e2fsck con il -D) quando si ha a che fare con una directory v.large esistente. Backup + succhia-e-vedi.

Ovviamente non mele alle mele qui, ma ho impostato un piccolo test e ho fatto quanto segue:

Creato 100.000 file da 512 byte in una directory ( dde /dev/urandomin un ciclo); ho dimenticato di cronometrarlo, ma ci sono voluti circa 15 minuti per creare quei file.

Esegui le seguenti operazioni per eliminare detti file:

ls -1 | wc -l && time find . -type f -delete

100000

real    0m4.208s
user    0m0.270s
sys     0m3.930s 

Questa è una scatola Pentium 4 da 2,8 GHz (credo che duecento GB IDE 7200 RPM; EXT3). Kernel 2.6.27.

A volte Perl può fare miracoli in casi come questo. Hai già provato se un piccolo script come questo potrebbe superare i comandi bash e shell di base?

#!/usr/bin/perl 
open(ANNOYINGDIR,"/path/to/your/directory");
@files = grep("/*\.png/", readdir(ANNOYINGDIR));
close(ANNOYINGDIR);

for (@files) {
    printf "Deleting %s\n",$_;
    unlink $_;
}

O un altro, forse anche più veloce, approccio Perl:

#!/usr/bin/perl
unlink(glob("/path/to/your/directory/*.png")) or die("Could not delete files, this happened: $!");

EDIT: Ho appena provato i miei script Perl. Quanto più prolisso fa qualcosa di giusto. Nel mio caso l'ho provato con un server virtuale con 256 MB di RAM e mezzo milione di file.

time find /test/directory | xargs rm i risultati:

real    2m27.631s
user    0m1.088s
sys     0m13.229s

rispetto a

time perl -e 'opendir(FOO,"./"); @files = readdir(FOO); closedir(FOO); for (@files) { unlink $_; }'

real    0m59.042s
user    0m0.888s
sys     0m18.737s

Da quello che ricordo l'eliminazione degli inode nel filesystem ext è O (n ^ 2), quindi più file si eliminano, più velocemente andrà il resto.

C'è stata una volta che ho dovuto affrontare un problema simile (anche se le mie stime hanno esaminato il tempo di cancellazione di circa 7 ore), alla fine è stato seguito il percorso suggerito da Jftuga nel primo commento .

Bene, questa non è una vera risposta, ma ...

Sarebbe possibile convertire il filesystem in ext4 e vedere se le cose cambiano?

Bene, questo è stato coperto in vari modi nel resto del thread, ma ho pensato di aggiungere due centesimi. Il colpevole delle prestazioni nel tuo caso è probabilmente readdir. Si sta recuperando un elenco di file che non sono necessariamente sequenziali sul disco e che causano l'accesso al disco ovunque quando si scollega. I file sono abbastanza piccoli che l'operazione di scollegamento probabilmente non salta troppo azzerando lo spazio. Se leggi readdir e poi ordina per inode crescente, probabilmente otterrai prestazioni migliori. Quindi readdir in ram (ordina per inode) -> scollega -> profitto.

Inode è un'approssimazione approssimativa qui penso .. ma basandosi sul tuo caso d'uso potrebbe essere abbastanza preciso ...

Probabilmente avrei tirato fuori un compilatore in C e fatto l'equivalente morale della tua sceneggiatura. Cioè, usa opendir(3)per ottenere un handle di directory, quindi usa readdir(3)per ottenere il nome dei file, quindi aggiusta i file mentre li scollego e ogni tanto stampa "% d file cancellati" (e possibilmente tempo trascorso o timestamp corrente).

Non mi aspetto che sia notevolmente più veloce della versione dello script della shell, è solo che sono abituato a dover strappare il compilatore di tanto in tanto, sia perché non c'è modo pulito di fare ciò che voglio dalla shell o perché sebbene fattibile in shell, è improduttivamente lento in quel modo.

Probabilmente stai riscontrando problemi di riscrittura con la directory. Prova a eliminare prima i file più recenti. Guarda le opzioni di mount che rimandano il writeback al disco.

Per una barra di avanzamento prova a eseguire qualcosa di simile rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

Ecco come elimino i milioni di file di traccia che a volte possono essere raccolti su un server di database Oracle di grandi dimensioni:

for i in /u*/app/*/diag/*/*/*/trace/*.tr? ; do rm $i; echo -n . ;  done

Trovo che ciò si traduca in una cancellazione abbastanza lenta che ha un basso impatto sulle prestazioni del server, di solito qualcosa sulla falsariga di un'ora per milione di file su una configurazione "tipica" 10.000 IOPS.

Occorreranno spesso alcuni minuti prima che le directory vengano scansionate, generato l'elenco di file iniziale e il primo file venga eliminato. Da lì in poi, a. viene ripetuto per ogni file eliminato.

Il ritardo causato dall'eco al terminale ha dimostrato un ritardo sufficiente a prevenire qualsiasi carico significativo durante la cancellazione.

È possibile utilizzare le funzionalità di parallelizzazione 'xargs':

ls -1|xargs -P nb_concurrent_jobs -n nb_files_by_job rm -rf

ls|cut -c -4|sort|uniq|awk '{ print "rm -rf " $1 }' | sh -x

in realtà, questo è un po 'meglio se la shell che usi fa l'espansione della riga di comando:

ls|cut -c -4|sort|uniq|awk '{ print "echo " $1 ";rm -rf " $1 "*"}' |sh