rm sur un répertoire avec des millions de fichiers

Contexte: serveur physique, âgé d'environ deux ans, disques SATA à 7 200 tr / min connectés à une carte RAID 3Ware, ext3 FS monté avec noatime et data = commandé, pas sous une charge folle, noyau 2.6.18-92.1.22.el5, temps de disponibilité 545 jours . Directory ne contient aucun sous-répertoire, mais des millions de petits fichiers (~ 100 octets), avec des fichiers plus volumineux (quelques Ko).

Nous avons un serveur qui est devenu un peu coucou au cours des derniers mois, mais nous ne l’avons remarqué que l’autre jour quand il a commencé à être incapable d’écrire dans un répertoire car il contenait trop de fichiers. Plus précisément, il a commencé à générer cette erreur dans / var / log / messages:

ext3_dx_add_entry: Directory index full!

Le disque en question a beaucoup d’inodes restants:

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

Donc, je suppose que cela signifie que nous atteignons la limite du nombre d'entrées pouvant être dans le fichier répertoire lui-même. Aucune idée du nombre de fichiers, mais il ne peut pas y avoir plus de trois millions à peu près, comme vous pouvez le constater. Ce n'est pas bien, remarquez! Mais c’est la première partie de ma question: quelle est exactement cette limite supérieure? Est-ce accordable? Avant que je me crié dessus, je veux le régler vers le bas ; cet énorme répertoire a causé toutes sortes de problèmes.

Quoi qu'il en soit, nous avons repéré le problème dans le code qui générait tous ces fichiers, et nous l'avons corrigé. Maintenant, je suis coincé avec la suppression du répertoire.

Quelques options ici:

1. rm -rf (dir)

   J'ai essayé ceci en premier. J'ai abandonné et je l'ai tué après une journée et demie sans impact perceptible.

2. unlink (2) sur le répertoire: Cela mérite certainement d'être pris en compte, mais la question est de savoir s'il serait plus rapide de supprimer les fichiers du répertoire via fsck que de supprimer via unlink (2). C'est-à-dire que, d'une manière ou d'une autre, je dois marquer ces inodes comme inutilisés. Bien entendu, cela suppose que je puisse dire à fsck de ne pas supprimer les entrées dans les fichiers de / lost + found; sinon, je viens de déplacer mon problème. En plus de toutes les autres préoccupations, après avoir lu un peu plus à ce sujet, il s'avère que je devrais probablement appeler des fonctions FS internes, car aucune des variantes unlink (2) que je peux trouver ne me permettrait de supprimer allègrement. un répertoire avec des entrées. Caca.
3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

   C'est en fait la version abrégée; le vrai que je suis en train d’exécuter, qui ajoute quelques rapports de progression et un arrêt net lorsque nous sommes à court de fichiers à supprimer, est le suivant:

   exportation i = 0;
   time (while [true]; do
     ls -Uf | tête -n 3 | grep -qF '.png' || Pause;
     ls -Uf | tête -n 10000 | xargs rm -f 2> / dev / null;
     exportation i = $ (($ i + 10000));
     echo "$ i ...";
   terminé )

   Cela semble fonctionner plutôt bien. Au moment où j'écris ces lignes, il a supprimé 260 000 fichiers au cours des trente dernières minutes.

1. Comme mentionné ci-dessus, la limite d'entrée par répertoire est-elle réglable?
2. Pourquoi a-t-il fallu "vrais 7m9.561s / utilisateur 0m0.001s / sys 0m0.001s" pour supprimer un fichier qui était le premier dans la liste renvoyée par ls -U, et il a fallu peut-être dix minutes pour supprimer les 10 000 premières entrées avec le commande en n ° 3, mais maintenant il roule assez bien? D'ailleurs, il en a supprimé 260 000 en une trentaine de minutes, mais il lui faut maintenant quinze minutes supplémentaires pour en supprimer 60 000 de plus. Pourquoi les énormes sautes de vitesse?
3. Y a-t-il une meilleure façon de faire ce genre de chose? Pas stocker des millions de fichiers dans un répertoire; Je sais que c'est idiot, et cela ne serait pas arrivé sous ma montre. Googler le problème et regarder à travers SF et SO offre beaucoup de variations sur ce findqui ne va pas être beaucoup plus rapide que mon approche pour plusieurs raisons évidentes. Mais l'idée de delete-via-fsck a-t-elle des jambes? Ou quelque chose d'autre entièrement? Je suis impatient d'entendre des réflexions originales (ou dans la boîte non connue).

Sortie du script final !:

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

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

Donc, trois millions de fichiers supprimés en un peu plus de quatre heures.

L’ data=writebackoption de montage mérite d’être essayée afin d’empêcher la journalisation du système de fichiers. Cela ne doit être effectué que pendant la période de suppression. Cependant, le serveur est en cours d'arrêt ou redémarré pendant l'opération de suppression.

Selon cette page ,

Certaines applications montrent une amélioration très significative de la vitesse d'utilisation. Par exemple, des améliorations de la vitesse peuvent être constatées (...) lorsque les applications créent et suppriment de gros volumes de petits fichiers.

L'option est définie dans fstabou pendant l'opération de montage, en remplaçant data=orderedpar data=writeback. Le système de fichiers contenant les fichiers à supprimer doit être remonté.

Une cause majeure de ce problème est la performance ext3 avec des millions de fichiers, mais la cause première de ce problème est différente.

Quand un répertoire doit être répertorié, readdir () est appelé sur le répertoire, ce qui donne une liste de fichiers. readdir est un appel posix, mais le véritable appel système Linux utilisé ici s'appelle 'getdents'. Getdents liste les entrées du répertoire en remplissant un tampon avec des entrées.

Le problème tient principalement au fait que readdir () utilise une taille de tampon fixe de 32 Ko pour extraire des fichiers. Lorsqu'un répertoire devient de plus en plus grand (la taille augmente à mesure que des fichiers sont ajoutés), ext3 lit de plus en plus lentement pour extraire des entrées et la taille de mémoire tampon supplémentaire de 32 Ko de readdir est suffisante pour inclure une fraction des entrées du répertoire. Readdir est ainsi mis en boucle, invoquant l'appel système coûteux, encore et encore.

Par exemple, sur un répertoire de test que j'ai créé et contenant plus de 2,6 millions de fichiers, l'exécution de "ls -1 | wc-l" affiche une grande sortie strace de nombreux appels système 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
...

De plus, le temps passé dans ce répertoire était significatif.

$ time ls -1 | wc -l
2616044

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

La méthode pour rendre ce processus plus efficace consiste à appeler getdents manuellement avec un tampon beaucoup plus volumineux. Cela améliore considérablement les performances.

Maintenant, vous n'êtes pas censé appeler getdents vous-même manuellement, il n'y a donc pas d'interface pour l'utiliser normalement (consultez la page de manuel relative à getdents pour voir!), Mais vous pouvez l' appeler manuellement et rendre votre appel d'appel système plus efficace.

Cela réduit considérablement le temps nécessaire pour récupérer ces fichiers. J'ai écrit un programme qui fait ça.

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

Bien que cela ne combat pas le problème fondamental sous-jacent (beaucoup de fichiers, dans un système de fichiers qui fonctionne mal). Cela risque d'être beaucoup, beaucoup plus rapide que la plupart des alternatives affichées.

En prévision, il convient de supprimer le répertoire affecté et de le refaire ensuite. La taille des répertoires n’augmente jamais et peut rester médiocre, même avec quelques fichiers, à cause de la taille du répertoire.

Edit: j'ai nettoyé cela un peu. Ajout d'une option pour vous permettre de supprimer sur la ligne de commande au moment de l'exécution et suppression d'un tas de trucs de promenade dans les arbres qui, honnêtement, rétrospectivement était au mieux discutable. Aussi a été montré pour produire une corruption de mémoire.

Vous pouvez maintenant faire dentls --delete /my/path

Nouveaux résultats Basé sur un répertoire de 1,82 million de fichiers.

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

Était un peu surpris cela fonctionne toujours si bien!

Serait-il possible de sauvegarder tous les autres fichiers de ce système de fichiers dans un emplacement de stockage temporaire, de reformater la partition, puis de restaurer les fichiers?

Il n'y a pas de limite de fichiers par répertoire dans ext3, mais uniquement la limite d'inode du système de fichiers (je pense cependant qu'il existe une limite quant au nombre de sous-répertoires).

Vous pouvez toujours avoir des problèmes après la suppression des fichiers.

Lorsqu'un répertoire contient des millions de fichiers, l'entrée de répertoire elle-même devient très grande. L'entrée du répertoire doit être analysée pour chaque opération de suppression, ce qui prend différentes durées pour chaque fichier, en fonction de l'emplacement de l'entrée. Malheureusement, même après la suppression de tous les fichiers, l’entrée du répertoire conserve sa taille. Par conséquent, les opérations supplémentaires nécessitant l'analyse de l'entrée du répertoire prendront encore beaucoup de temps, même si le répertoire est maintenant vide. Le seul moyen de résoudre ce problème consiste à renommer le répertoire, à en créer un nouveau avec l'ancien nom et à transférer tous les fichiers restants dans le nouveau. Supprimez ensuite celui qui a été renommé.

Je ne l'ai pas évalué, mais ce type l'a fait :

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

find n'a tout simplement pas fonctionné pour moi, même après avoir modifié les paramètres de ext3 fs comme suggéré par les utilisateurs ci-dessus. Consommé beaucoup trop de mémoire. Ce script PHP a fait l'affaire - rapide, utilisation du processeur insignifiante, utilisation de la mémoire insignifiante:

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

J'ai posté un rapport de bogue concernant ce problème avec find: http://savannah.gnu.org/bugs/?31961

J'ai récemment fait face à un problème similaire et j'étais incapable d'obtenir la data=writebacksuggestion de ring0 de fonctionner (probablement parce que les fichiers se trouvent sur ma partition principale). En cherchant des solutions de contournement, je suis tombé sur ceci:

tune2fs -O ^has_journal <device>

Cela désactive complètement la journalisation, quelle que soit l' dataoption donnée à mount. J'ai combiné cela avec noatimeet le volume était dir_indexréglé, et cela semblait bien fonctionner. La suppression s’est en fait terminée sans que je n’aie besoin de la supprimer, mon système est resté réactif et il est maintenant remis en service (avec journalisation réactivée) sans aucun problème.

Assurez-vous de le faire:

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

ce qui devrait aussi accélérer les choses.

La commande est très lente. Essayer:

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

Est dir_indexdéfini pour le système de fichiers? ( tune2fs -l | grep dir_index) Sinon, activez-le. C'est habituellement pour le nouveau RHEL.

Il y a quelques années, j'ai trouvé un répertoire de 16 millions de fichiers XML dans le /système de fichiers. En raison de la criticité du serveur, nous avons utilisé la commande suivante qui a duré environ 30 heures :

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

Il s’agissait d’un vieux disque dur à 7 200 tr / min et, malgré le goulot d’étranglement IO et les pics de processeur, l’ancien serveur Web poursuivait son service.

Mon option préférée est l'approche newfs, déjà suggérée. Le problème fondamental est, encore une fois, comme cela a déjà été noté, le balayage linéaire pour gérer la suppression est problématique.

rm -rfdevrait être presque optimal pour un système de fichiers local (NFS serait différent). Mais avec des millions de fichiers, 36 octets par nom de fichier et 4 par inode (une estimation, ne vérifiant pas la valeur de ext3), cela représente 40 * millions, à conserver dans la RAM uniquement pour le répertoire.

En un rien de temps, vous écrasez la mémoire cache de métadonnées du système de fichiers sous Linux, de sorte que les blocs d'une page du fichier de répertoire soient supprimés pendant que vous utilisez encore une autre partie. le fichier est supprimé. Le réglage des performances Linux n’est pas de mon ressort, mais / proc / sys / {vm, fs} / contient probablement quelque chose de pertinent.

Si vous pouvez vous permettre des temps d'arrêt, vous pouvez envisager d'activer la fonctionnalité dir_index. Il bascule l'index de répertoire de linéaire à quelque chose de beaucoup plus optimal pour la suppression dans les grands répertoires (arbres binaires hachés). tune2fs -O dir_index ...suivi de e2fsck -Dtravaillerait. Cependant, bien que je sois confiant que cela aiderait avant qu'il y ait des problèmes, je ne sais pas comment la conversion (e2fsck avec le -D) se comporte lorsqu'il s'agit d'un répertoire v.large existant. Sauvegardes + sucer-it-and-see.

Évidemment pas des pommes aux pommes ici, mais j'ai installé un petit test et fait ce qui suit:

Création de 100 000 fichiers de 512 octets dans un répertoire ( ddet /dev/urandomdans une boucle); oublié de chronométrer, mais il a fallu environ 15 minutes pour créer ces fichiers.

A exécuté ce qui suit pour supprimer lesdits fichiers:

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

100000

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

Il s’agit d’un boîtier Pentium 4 à 2,8 GHz (quelques centaines de Go IDE 7200 tr / min je pense; EXT3). Noyau 2.6.27.

Parfois, Perl peut faire des merveilles dans des cas comme celui-ci. Avez-vous déjà essayé si un petit script comme celui-ci pouvait surpasser bash et les commandes de base du shell?

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

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

Ou une autre approche, peut-être même plus rapide, de Perl:

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

MODIFIER: Je viens d'essayer mes scripts Perl. Le plus verbeux fait quelque chose de bien. Dans mon cas, j'ai essayé avec un serveur virtuel avec 256 Mo de RAM et un demi-million de fichiers.

time find /test/directory | xargs rm résultats:

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

par rapport à

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

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

De ce que je me souviens de la suppression des inodes dans les systèmes de fichiers ext est O (n ^ 2), donc plus vous supprimez de fichiers, plus vite le reste ira.

Une fois, j’ai été confronté à un problème similaire (bien que mes estimations aient pris environ 7 heures), c’est finalement le chemin suggéré par jftuga dans le premier commentaire .

Eh bien, ce n'est pas une vraie réponse, mais ...

Serait-il possible de convertir le système de fichiers en ext4 et de voir si les choses changent?

D'accord, cela a été couvert de différentes manières dans le reste du fil, mais je pensais que je mettrais mes deux sous. Le coupable de performance dans votre cas est probablement readdir. Vous récupérez une liste de fichiers qui ne sont pas nécessairement séquentiels sur le disque, ce qui entraîne un accès au disque partout lorsque vous supprimez le lien. Les fichiers sont suffisamment petits pour que l'opération de dissociation ne saute probablement pas trop au zéro. Si vous readdir puis triez par inode croissant, vous obtiendrez probablement de meilleures performances. Donc readdir dans la RAM (trier par inode) -> unlink -> profit.

Inode est une approximation approximative ici, mais je pense .. mais sur la base de votre cas d'utilisation, il pourrait être assez précis ...

J'aurais probablement sorti un compilateur C et fait l'équivalent moral de votre script. Autrement dit, utilisez opendir(3)pour obtenir un descripteur de répertoire, puis utilisezreaddir(3) pour obtenir le nom des fichiers, puis compilez les fichiers au fur et à mesure que je les dissocie et imprime de temps en temps "% d fichiers supprimés" (et éventuellement le temps écoulé ou l'horodatage en cours).

Je ne m'attends pas à ce qu'il soit sensiblement plus rapide que la version du script shell, c'est simplement que je suis habitué à extraire le compilateur de temps en temps, soit parce qu'il n'y a pas de moyen propre de faire ce que je veux dans le shell ou parce que bien que réalisable en shell, il est lent de façon improductive.

Vous êtes probablement confronté à des problèmes de réécriture du répertoire. Essayez de supprimer les fichiers les plus récents en premier. Examinez les options de montage qui différeront l'écriture sur le disque.

Pour une barre de progression, essayez quelque chose comme: rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

Voici comment je supprime les millions de fichiers de trace qui peuvent parfois se rassembler sur un grand serveur de base de données Oracle:

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

Je constate que cela entraîne une suppression assez lente qui a un impact faible sur les performances du serveur, généralement une heure par million de fichiers sur une configuration "typique" de 10 000 IOPS.

Plusieurs minutes sont nécessaires avant l'analyse des répertoires, la génération de la liste de fichiers initiale et la suppression du premier fichier. À partir de là, a. est répété pour chaque fichier supprimé.

Le retard causé par l'écho au terminal s'est avéré suffisamment retard pour empêcher toute charge significative pendant la suppression.

Vous pouvez utiliser les fonctionnalités de parallélisation '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 fait, celui-ci est un peu meilleur si le shell que vous utilisez ne développe pas en ligne de commande:

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