rm en un directorio con millones de archivos

Antecedentes: servidor físico, aproximadamente dos años de antigüedad, unidades SATA de 7200 RPM conectadas a una tarjeta RAID 3Ware, ext3 FS montado noatime y data = ordenado, no bajo carga loca, kernel 2.6.18-92.1.22.el5, tiempo de actividad 545 días . El directorio no contiene ningún subdirectorio, solo millones de archivos pequeños (~ 100 bytes), con algunos más grandes (algunos KB).

Tenemos un servidor que se ha vuelto un poco loco en el transcurso de los últimos meses, pero solo lo notamos el otro día cuando comenzó a no poder escribir en un directorio debido a que contenía demasiados archivos. Específicamente, comenzó a arrojar este error en / var / log / messages:

ext3_dx_add_entry: Directory index full!

El disco en cuestión tiene muchos inodos restantes:

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

Supongo que eso significa que llegamos al límite de cuántas entradas pueden estar en el archivo de directorio. No tengo idea de cuántos archivos serían, pero no puede ser más, como puede ver, más de tres millones. ¡No es que eso sea bueno, eso sí! Pero esa es la primera parte de mi pregunta: ¿cuál es exactamente ese límite superior? ¿Es sintonizable? Antes de gritar en Las-Quiero ajustarlo hacia abajo ; Este enorme directorio causó todo tipo de problemas.

De todos modos, rastreamos el problema en el código que estaba generando todos esos archivos, y lo hemos corregido. Ahora estoy atascado con la eliminación del directorio.

Algunas opciones aquí:

1. rm -rf (dir)

   Intenté esto primero. Me di por vencido y lo maté después de que hubiera funcionado durante un día y medio sin ningún impacto perceptible.

2. unlink (2) en el directorio: Definitivamente vale la pena considerarlo, pero la pregunta es si sería más rápido eliminar los archivos dentro del directorio a través de fsck que eliminarlos a través de unlink (2). Es decir, de una forma u otra, tengo que marcar esos inodes como no utilizados. Esto supone, por supuesto, que puedo decirle a fsck que no suelte entradas a los archivos en / lost + found; de lo contrario, acabo de mover mi problema. Además de todas las otras preocupaciones, después de leer un poco más sobre esto, resulta que probablemente tenga que llamar a algunas funciones internas de FS, ya que ninguna de las variantes de Unlink (2) que puedo encontrar me permitiría eliminar alegremente un directorio con entradas en el mismo. Pooh
3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

   Esta es en realidad la versión abreviada; el verdadero que estoy ejecutando, que solo agrega algunos informes de progreso y una parada limpia cuando nos quedamos sin archivos para eliminar, es:

   exportar i = 0;
   tiempo (mientras [verdadero]; hacer
     ls -Uf | cabeza -n 3 | grep -qF '.png' || rotura;
     ls -Uf | cabeza -n 10000 | xargs rm -f 2> / dev / null;
     exportar i = $ (($ i + 10000));
     echo "$ i ...";
   hecho )

   Esto parece estar funcionando bastante bien. Mientras escribo esto, ha eliminado 260,000 archivos en los últimos treinta minutos más o menos.

1. Como se mencionó anteriormente, ¿se puede ajustar el límite de entrada por directorio?
2. ¿Por qué tardó "7m9.561s reales / usuario 0m0.001s / sys 0m0.001s" para eliminar un solo archivo que fue el primero en la lista devuelto por ls -U, y tardó tal vez diez minutos en eliminar las primeras 10.000 entradas con el comando en el n. ° 3, pero ahora se está transportando muy felizmente. Para el caso, eliminó 260,000 en aproximadamente treinta minutos, pero ahora le tomó otros quince minutos eliminar 60,000 más. ¿Por qué los enormes cambios de velocidad?
3. ¿Hay una mejor manera de hacer este tipo de cosas? No almacenar millones de archivos en un directorio; Sé que es una tontería, y no habría sucedido en mi reloj. Buscar en Google el problema y mirar SF y SO ofrece muchas variaciones findque no van a ser significativamente más rápidas que mi enfoque por varias razones evidentes. Pero, ¿la idea delete-via-fsck tiene piernas? ¿O algo completamente diferente? Estoy ansioso por escuchar el pensamiento fuera de la caja (o dentro de la caja no conocida).

Salida del guión final !:

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

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

Entonces, tres millones de archivos eliminados en poco más de cuatro horas.

La data=writebackopción de montaje merece ser probada, para evitar el registro en diario del sistema de archivos. Esto debe hacerse solo durante el tiempo de eliminación; sin embargo, existe el riesgo de que el servidor se apague o reinicie durante la operación de eliminación.

De acuerdo con esta página ,

Algunas aplicaciones muestran una mejora de velocidad muy significativa cuando se usa. Por ejemplo, se pueden ver mejoras de velocidad (...) cuando las aplicaciones crean y eliminan grandes volúmenes de archivos pequeños.

La opción se establece en fstabo durante la operación de montaje, reemplazando data=orderedcon data=writeback. El sistema de archivos que contiene los archivos que se eliminarán debe volver a montarse.

Si bien una de las principales causas de este problema es el rendimiento ext3 con millones de archivos, la causa raíz real de este problema es diferente.

Cuando un directorio necesita ser listado, se llama a readdir () en el directorio que produce una lista de archivos. readdir es una llamada posix, pero la llamada real del sistema Linux que se usa aquí se llama 'getdents'. Los solicitantes enumeran las entradas del directorio llenando un búfer con entradas.

El problema se debe principalmente al hecho de que readdir () usa un tamaño de búfer fijo de 32Kb para recuperar archivos. A medida que un directorio se hace más y más grande (el tamaño aumenta a medida que se agregan archivos) ext3 se vuelve más y más lento para buscar entradas y el tamaño de búfer adicional de 32 Kb de readdir solo es suficiente para incluir una fracción de las entradas en el directorio. Esto hace que readdir se repita una y otra vez e invoque la costosa llamada del sistema una y otra vez.

Por ejemplo, en un directorio de prueba que creé con más de 2.6 millones de archivos dentro, ejecutar "ls -1 | wc-l" muestra una gran salida de muchas llamadas al 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
...

Además, el tiempo que pasó en este directorio fue significativo.

$ time ls -1 | wc -l
2616044

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

El método para hacer de este un proceso más eficiente es llamar a getdents manualmente con un búfer mucho más grande. Esto mejora el rendimiento significativamente.

Ahora, se supone que no debe llamar a getdents manualmente, por lo que no existe una interfaz para usarlo normalmente (consulte la página del manual para ver getdents), sin embargo, puede llamarlo manualmente y hacer que la invocación de llamadas de su sistema sea mucho más eficiente.

Esto reduce drásticamente el tiempo que lleva recuperar estos archivos. Escribí un programa que hace esto.

/* 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);
}

Si bien esto no combate el problema fundamental subyacente (muchos archivos, en un sistema de archivos que funciona mal en él). Es probable que sea mucho, mucho más rápido que muchas de las alternativas publicadas.

Como previsión, uno debe eliminar el directorio afectado y rehacerlo después. Los directorios solo aumentan de tamaño y pueden seguir teniendo un bajo rendimiento, incluso con algunos archivos dentro debido al tamaño del directorio.

Editar: he limpiado esto bastante. Se agregó una opción para permitirle eliminar en la línea de comandos en tiempo de ejecución y eliminó un montón de cosas del paseo del árbol que, sinceramente, mirar hacia atrás era cuestionable en el mejor de los casos. También se demostró que produce daños en la memoria.

Ahora puedes hacer dentls --delete /my/path

Nuevos resultados Basado en un directorio con 1.82 millones de archivos.

## 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

Me sorprendió que esto todavía funcione tan bien.

¿Sería posible hacer una copia de seguridad de todos los demás archivos de este sistema de archivos en una ubicación de almacenamiento temporal, formatear la partición y luego restaurar los archivos?

No hay límite por archivo de directorio en ext3, solo el límite de inodo del sistema de archivos (aunque creo que hay un límite en el número de subdirectorios).

Es posible que aún tenga problemas después de eliminar los archivos.

Cuando un directorio tiene millones de archivos, la entrada del directorio se vuelve muy grande. La entrada del directorio tiene que ser escaneada para cada operación de eliminación, y eso toma varias cantidades de tiempo para cada archivo, dependiendo de dónde se encuentre su entrada. Desafortunadamente, incluso después de que se hayan eliminado todos los archivos, la entrada del directorio conserva su tamaño. Por lo tanto, las operaciones adicionales que requieren escanear la entrada del directorio aún llevarán mucho tiempo, incluso si el directorio ahora está vacío. La única forma de resolver ese problema es cambiar el nombre del directorio, crear uno nuevo con el nombre anterior y transferir los archivos restantes al nuevo. Luego borre el renombrado.

No lo he comparado, pero este tipo hizo :

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

find simplemente no funcionó para mí, incluso después de cambiar los parámetros de ext3 fs como lo sugirieron los usuarios anteriores. Consumió demasiada memoria. Este script PHP hizo el truco: uso de CPU rápido e insignificante, uso de memoria insignificante:

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

Publiqué un informe de error con respecto a este problema con find: http://savannah.gnu.org/bugs/?31961

Recientemente me enfrenté a un problema similar y no pude obtener la data=writebacksugerencia de ring0 para trabajar (posiblemente debido al hecho de que los archivos están en mi partición principal). Mientras investigaba soluciones, me topé con esto:

tune2fs -O ^has_journal <device>

Esto apagará el diario por completo, independientemente de la dataopción que le des mount. Combiné esto con noatimey el volumen se había dir_indexestablecido, y parecía funcionar bastante bien. La eliminación en realidad terminó sin que tuviera que matarla, mi sistema siguió respondiendo y ahora está funcionando nuevamente (con el diario nuevamente) sin problemas.

Asegúrate de hacer:

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

lo que debería acelerar un poco las cosas también.

Es un comando muy lento. Tratar:

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

¿Está dir_indexconfigurado para el sistema de archivos? ( tune2fs -l | grep dir_index) Si no, habilítelo. Suele estar activado para el nuevo RHEL.

Hace un par de años, encontré un directorio con 16 millones de archivos XML en el /sistema de archivos. Debido a la crítica del servidor, utilizamos el siguiente comando que tardó aproximadamente 30 horas en finalizar:

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

Era un viejo disco duro de 7200 rpm , y a pesar del cuello de botella de IO y los picos de CPU, el viejo servidor web continuó su servicio.

Mi opción preferida es el enfoque newfs, ya sugerido. El problema básico es, nuevamente como ya se señaló, el escaneo lineal para manejar la eliminación es problemático.

rm -rfdebería ser casi óptimo para un sistema de archivos local (NFS sería diferente). Pero en millones de archivos, 36 bytes por nombre de archivo y 4 por inodo (una suposición, sin verificar el valor de ext3), eso es 40 * millones, que se mantendrán en la RAM solo para el directorio.

Supongo que está agotando la memoria caché de metadatos del sistema de archivos en Linux, por lo que los bloques para una página del archivo de directorio se eliminan mientras todavía está usando otra parte, solo para golpear esa página del caché nuevamente la próxima vez El archivo es eliminado. El ajuste del rendimiento de Linux no es mi área, pero / proc / sys / {vm, fs} / probablemente contenga algo relevante.

Si puede permitirse el tiempo de inactividad, puede considerar activar la función dir_index. Cambia el índice del directorio de lineal a algo mucho más óptimo para su eliminación en directorios grandes (hashed b-trees). tune2fs -O dir_index ...seguido por e2fsck -Dfuncionaría. Sin embargo, aunque estoy seguro de que esto ayudaría antes de que haya problemas, no sé cómo se realiza la conversión (e2fsck con el -D) cuando se trata de un directorio v.large existente. Copias de seguridad + suck-it-and-see.

Obviamente no manzanas con manzanas aquí, pero configuré una pequeña prueba e hice lo siguiente:

Creó 100,000 archivos de 512 bytes en un directorio ( ddy/dev/urandom en un bucle); olvidé cronometrarlo, pero me llevó aproximadamente 15 minutos crear esos archivos.

Ejecutó lo siguiente para eliminar dichos archivos:

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

100000

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

Esta es una caja Pentium 4 2.8GHz (un par de cientos de GB IDE 7200 RPM, creo; EXT3). Kernel 2.6.27.

A veces, Perl puede hacer maravillas en casos como este. ¿Ya has probado si un script pequeño como este podría superar a bash y los comandos básicos del shell?

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

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

U otro enfoque de Perl, quizás incluso más rápido:

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

EDITAR: Acabo de probar mis scripts de Perl. Cuanto más detallado se hace algo bien. En mi caso, probé esto con un servidor virtual con 256 MB de RAM y medio millón de archivos.

time find /test/directory | xargs rm resultados:

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

comparado con

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

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

Por lo que recuerdo, la eliminación de inodes en los sistemas de archivos ext es O (n ^ 2), por lo que cuantos más archivos elimine, más rápido irá el resto.

Hubo una vez que me enfrenté a un problema similar (aunque mis estimaciones miraron el tiempo de eliminación de ~ 7h), al final fue la ruta sugerida por jftuga en el primer comentario .

Bueno, esta no es una respuesta real, pero ...

¿Sería posible convertir el sistema de archivos a ext4 y ver si las cosas cambian?

De acuerdo, esto se ha cubierto de varias maneras en el resto del hilo, pero pensé en tirar mis dos centavos. El culpable de rendimiento en su caso es probablemente readdir. Está obteniendo una lista de archivos que no son necesariamente secuenciales en el disco, lo que está causando acceso al disco en todo el lugar cuando se desvincula. Los archivos son lo suficientemente pequeños como para que la operación de desvinculación probablemente no salte demasiado poniendo a cero el espacio. Si lee y luego ordena por inodo ascendente, probablemente obtendrá un mejor rendimiento. Entonces readdir en ram (ordenar por inodo) -> desvincular -> beneficio.

Inode es una aproximación aproximada aquí, creo ... pero basándome en su caso de uso podría ser bastante preciso ...

Probablemente habría sacado un compilador de C y hecho el equivalente moral de tu guión. Es decir, use opendir(3)para obtener un identificador de directorio, luego use readdir(3)para obtener el nombre de los archivos, luego registre los archivos a medida que los desvío y de vez en cuando imprima "% d archivos eliminados" (y posiblemente el tiempo transcurrido o la marca de tiempo actual).

No espero que sea notablemente más rápido que la versión del script de shell, es solo que estoy acostumbrado a tener que extraer el compilador de vez en cuando, ya sea porque no hay una manera limpia de hacer lo que quiero del shell o porque Si bien es factible en shell, es improductivamente lento de esa manera.

Es probable que tenga problemas de reescritura con el directorio. Intente eliminar primero los archivos más nuevos. Mire las opciones de montaje que diferirán la reescritura en el disco.

Para una barra de progreso intente ejecutar algo como rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

Así es como elimino los millones de archivos de rastreo que a veces se pueden reunir en un gran servidor de base de datos Oracle:

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

Me parece que esto da como resultado una eliminación bastante lenta que tiene un bajo impacto en el rendimiento del servidor, generalmente algo así como una hora por millón de archivos en una configuración "típica" de 10,000 IOPS.

A menudo tomará varios minutos antes de que se hayan escaneado los directorios, se haya generado la lista de archivos inicial y se elimine el primer archivo. De allí en adelante, a. se repite para cada archivo eliminado.

La demora causada por el eco en el terminal ha demostrado ser una demora suficiente para evitar cualquier carga significativa mientras la eliminación está progresando.

Puede usar las funciones de paralelización de '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

en realidad, este es un poco mejor si el shell que usas sí expande la línea de comandos:

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