rm pada direktori dengan jutaan file

Latar belakang: server fisik, sekitar dua tahun, drive SATA 7200-RPM terhubung ke kartu RAID 3Ware, noatime yang dipasang di ext3 FS dan data = dipesan, bukan di bawah beban gila, kernel 2.6.18-92.1.22.el5, uptime 545 hari . Direktori tidak mengandung subdirektori, hanya jutaan file kecil (~ 100 byte), dengan beberapa yang lebih besar (beberapa KB).

Kami memiliki server yang sudah agak cuckoo selama beberapa bulan terakhir, tetapi kami baru menyadarinya pada hari lain ketika server mulai tidak dapat menulis ke direktori karena mengandung terlalu banyak file. Secara khusus, itu mulai melempar kesalahan ini di / var / log / messages:

ext3_dx_add_entry: Directory index full!

Disk yang dimaksud memiliki banyak inode yang tersisa:

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

Jadi saya menduga itu berarti kita mencapai batas berapa banyak entri dapat di file direktori itu sendiri. Tidak tahu berapa banyak file yang akan, tetapi tidak bisa lebih, seperti yang Anda lihat, lebih dari tiga juta. Bukan itu bagus, ingatlah! Tapi itu bagian pertama dari pertanyaan saya: persis apa batas atas itu? Apakah bisa merdu? Sebelum saya dimarahi - saya ingin meremehkannya ; direktori besar ini menyebabkan segala macam masalah.

Bagaimanapun, kami melacak masalah dalam kode yang menghasilkan semua file itu, dan kami telah memperbaikinya. Sekarang saya terjebak dengan menghapus direktori.

Beberapa opsi di sini:

1. rm -rf (dir)

   Saya mencoba ini dulu. Saya menyerah dan membunuhnya setelah berjalan selama satu setengah hari tanpa dampak yang jelas.

2. batalkan tautan (2) pada direktori: Pasti layak dipertimbangkan, tetapi pertanyaannya adalah apakah akan lebih cepat untuk menghapus file di dalam direktori melalui fsck daripada menghapus melalui batalkan tautan (2). Artinya, dengan satu atau lain cara, saya harus menandai inode tersebut sebagai tidak terpakai. Ini mengasumsikan, tentu saja, bahwa saya dapat memberitahu fsck untuk tidak menjatuhkan entri ke file in / lost + found; jika tidak, saya baru saja memindahkan masalah saya. Selain semua kekhawatiran lain, setelah membaca tentang ini sedikit lebih banyak, ternyata saya mungkin harus memanggil beberapa fungsi FS internal, karena tidak ada varian unlink (2) yang dapat saya temukan yang akan memungkinkan saya untuk menghapus dengan blithely direktori dengan entri di dalamnya. Pooh.
3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

   Ini sebenarnya adalah versi singkat; yang sebenarnya saya jalankan, yang hanya menambahkan beberapa pelaporan kemajuan dan berhenti bersih ketika kita kehabisan file untuk dihapus, adalah:

   ekspor i = 0;
   waktu (sementara [benar]; lakukan
     ls -Uf | kepala -n 3 | grep -qF '.png' || istirahat;
     ls -Uf | kepala -n 10000 | xargs rm -f 2> / dev / null;
     ekspor i = $ (($ i + 10000));
     gema "$ i ...";
   Selesai )

   Ini sepertinya bekerja dengan baik. Saat saya menulis ini, ia telah menghapus 260.000 file dalam sekitar tiga puluh menit terakhir.

1. Seperti disebutkan di atas, apakah batas entri per-direktori dapat diatur?
2. Mengapa diperlukan "real 7m9.561s / pengguna 0m0.001s / sys 0m0.001s" untuk menghapus satu file yang merupakan yang pertama dalam daftar yang dikembalikan oleh ls -U, dan mungkin butuh sepuluh menit untuk menghapus 10.000 entri pertama dengan perintah di # 3, tapi sekarang sudah cukup senang? Untuk itu, itu dihapus 260.000 dalam waktu sekitar tiga puluh menit, tetapi sekarang butuh lima belas menit lagi untuk menghapus 60.000 lebih. Mengapa ayunan besar dalam kecepatan?
3. Apakah ada cara yang lebih baik untuk melakukan hal semacam ini? Tidak menyimpan jutaan file dalam direktori; Saya tahu itu konyol, dan itu tidak akan terjadi pada jam tangan saya. Menelusuri masalah dan melihat melalui SF dan SO menawarkan banyak variasi findyang tidak akan secara signifikan lebih cepat daripada pendekatan saya karena beberapa alasan yang jelas. Tapi apakah ide delete-via-fsck punya kaki? Atau sesuatu yang lain sama sekali? Saya ingin sekali mendengar pemikiran out-of-the-box (atau di dalam-tidak-terkenal).

Output skrip akhir !:

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

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

Jadi, tiga juta file dihapus dalam waktu lebih dari empat jam.

The data=writebackmount option layak untuk dicoba, untuk mencegah journal dari sistem file. Ini harus dilakukan hanya selama waktu penghapusan, namun ada risiko jika server sedang dimatikan atau di-reboot selama operasi penghapusan.

Menurut halaman ini ,

Beberapa aplikasi menunjukkan peningkatan kecepatan yang sangat signifikan ketika digunakan. Misalnya, peningkatan kecepatan dapat dilihat (...) ketika aplikasi membuat dan menghapus volume besar file kecil.

Opsi ini diatur dalam fstabatau selama operasi pemasangan, diganti data=ordereddengan data=writeback. Sistem file yang berisi file yang akan dihapus harus di-remount.

Sementara penyebab utama masalah ini adalah kinerja ext3 dengan jutaan file, penyebab sebenarnya dari masalah ini berbeda.

Ketika direktori perlu terdaftar readdir () dipanggil pada direktori yang menghasilkan daftar file. readdir adalah panggilan posix, tetapi panggilan sistem Linux yang digunakan di sini disebut 'getdents'. Entri daftar direktori entri dengan mengisi buffer dengan entri.

Masalahnya terutama karena fakta bahwa readdir () menggunakan ukuran buffer tetap sebesar 32Kb untuk mengambil file. Ketika direktori semakin besar dan lebih besar (ukurannya bertambah ketika file ditambahkan) ext3 semakin lambat untuk mengambil entri dan ukuran buffer 32Kb readdir tambahan hanya cukup untuk memasukkan sebagian kecil dari entri dalam direktori. Ini menyebabkan readdir berulang-ulang dan memanggil system call yang mahal berulang kali.

Sebagai contoh, pada direktori pengujian yang saya buat dengan lebih dari 2,6 juta file di dalamnya, menjalankan "ls -1 | wc-l" menunjukkan output strace besar dari banyak panggilan sistem 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
...

Selain itu waktu yang dihabiskan dalam direktori ini sangat signifikan.

$ time ls -1 | wc -l
2616044

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

Metode untuk menjadikan ini proses yang lebih efisien adalah dengan memanggil getdents secara manual dengan buffer yang jauh lebih besar. Ini meningkatkan kinerja secara signifikan.

Sekarang, Anda tidak seharusnya memanggil getdents sendiri secara manual sehingga tidak ada antarmuka untuk menggunakannya secara normal (lihat halaman manual untuk getdents untuk melihat!), Namun Anda dapat memanggilnya secara manual dan membuat doa pemanggilan sistem Anda lebih efisien.

Ini secara drastis mengurangi waktu yang diperlukan untuk mengambil file-file ini. Saya menulis sebuah program yang melakukan ini.

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

Meskipun ini tidak memerangi masalah mendasar yang mendasarinya (banyak file, dalam sistem file yang berkinerja buruk dalam hal itu). Kemungkinan besar, jauh lebih cepat daripada banyak alternatif yang diposting.

Sebagai pemikiran, seseorang harus menghapus direktori yang terkena dampak dan membuat ulang setelahnya. Direktori hanya bertambah ukurannya dan dapat tetap berkinerja buruk bahkan dengan beberapa file di dalamnya karena ukuran direktori.

Sunting: Saya sudah membersihkan ini sedikit. Menambahkan opsi untuk memungkinkan Anda menghapus pada baris perintah saat runtime dan menghapus banyak hal treewalk yang, jujur ​​melihat ke belakang dipertanyakan di terbaik. Juga terbukti menghasilkan korupsi memori.

Sekarang Anda bisa melakukannya dentls --delete /my/path

Hasil baru. Didasarkan pada direktori dengan 1,82 juta 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

Terkejut ini masih bekerja dengan baik!

Apakah mungkin untuk membuat cadangan semua file lain dari sistem file ini ke lokasi penyimpanan sementara, memformat ulang partisi, dan kemudian mengembalikan file?

Tidak ada batas per direktori file dalam ext3 hanya batas inode filesystem (saya pikir ada batas pada jumlah subdirektori meskipun).

Anda mungkin masih mengalami masalah setelah menghapus file.

Ketika sebuah direktori memiliki jutaan file, entri direktori itu sendiri menjadi sangat besar. Entri direktori harus dipindai untuk setiap operasi penghapusan, dan itu membutuhkan berbagai jumlah waktu untuk setiap file, tergantung di mana entri itu berada. Sayangnya bahkan setelah semua file dihapus, entri direktori mempertahankan ukurannya. Jadi operasi lebih lanjut yang memerlukan pemindaian entri direktori masih akan memakan waktu lama bahkan jika direktori sekarang kosong. Satu-satunya cara untuk mengatasi masalah itu adalah mengubah nama direktori, membuat yang baru dengan nama lama, dan mentransfer file yang tersisa ke yang baru. Kemudian hapus yang diganti namanya.

Saya belum membandingkannya, tetapi orang ini melakukannya :

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

temukan sama sekali tidak bekerja untuk saya, bahkan setelah mengubah parameter fs ext3 seperti yang disarankan oleh pengguna di atas. Memori yang dikonsumsi terlalu banyak. Script PHP ini melakukan trik - penggunaan CPU yang cepat dan tidak signifikan, penggunaan memori yang tidak signifikan:

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

Saya memposting laporan bug mengenai masalah ini dengan menemukan: http://savannah.gnu.org/bugs/?31961

Saya baru-baru ini menghadapi masalah yang sama dan tidak bisa mendapatkan data=writebacksaran ring0 untuk bekerja (mungkin karena fakta bahwa file-file tersebut ada di partisi utama saya). Saat mencari solusi, saya menemukan ini:

tune2fs -O ^has_journal <device>

Ini akan mematikan penjurnalan sepenuhnya, terlepas dari dataopsi yang diberikan untuk mount. Saya menggabungkan ini dengan noatimedan volume telah dir_indexdiatur, dan tampaknya bekerja dengan cukup baik. Penghapusan benar-benar selesai tanpa saya perlu membunuhnya, sistem saya tetap responsif, dan sekarang kembali aktif dan berjalan (dengan penjurnalan kembali aktif) tanpa masalah.

Pastikan Anda melakukannya:

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

yang seharusnya mempercepat sedikit juga.

Perintahnya sangat lambat. Mencoba:

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

Sudah dir_indexdiatur untuk sistem file? ( tune2fs -l | grep dir_index) Jika tidak, aktifkan. Biasanya aktif untuk RHEL baru.

Beberapa tahun yang lalu, saya menemukan direktori dengan 16 juta file XML di sistem /file. Karena kritikan server, kami menggunakan perintah berikut yang memakan waktu sekitar 30 jam untuk menyelesaikan:

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

Itu adalah hdd 7200 rpm lama , dan meskipun hambatan IO dan paku CPU, server web lama melanjutkan layanannya.

Opsi pilihan saya adalah pendekatan newfs, sudah disarankan. Masalah dasarnya adalah, sekali lagi seperti yang sudah dicatat, pemindaian linier untuk menangani penghapusan bermasalah.

rm -rfharus mendekati optimal untuk sistem file lokal (NFS akan berbeda). Tetapi pada jutaan file, 36 byte per nama file dan 4 per inode (tebakan, tidak memeriksa nilai untuk ext3), itu 40 * jutaan, harus disimpan dalam RAM hanya untuk direktori.

Pada tebakan, Anda meronta-ronta memori cache metadata sistem file di Linux, sehingga blok untuk satu halaman file direktori sedang dihapus sementara Anda masih menggunakan bagian lain, hanya untuk menekan halaman cache lagi ketika berikutnya file dihapus. Penyesuaian kinerja Linux bukan area saya, tetapi / proc / sys / {vm, fs} / mungkin berisi sesuatu yang relevan.

Jika Anda dapat melakukan downtime, Anda dapat mempertimbangkan untuk mengaktifkan fitur dir_index. Ini mengalihkan indeks direktori dari linear ke sesuatu yang jauh lebih optimal untuk dihapus dalam direktori besar (hashed b-tree). tune2fs -O dir_index ...diikuti oleh e2fsck -Dakan bekerja. Namun, sementara saya yakin ini akan membantu sebelum ada masalah, saya tidak tahu bagaimana kinerja konversi (e2fsck dengan -D) dilakukan ketika berhadapan dengan direktori v.large yang ada. Backup + pay-it-and-see.

Jelas bukan apel untuk apel di sini, tapi saya menyiapkan sedikit tes dan melakukan yang berikut:

Menciptakan 100.000 file 512-byte dalam suatu direktori ( dddan /dev/urandomdalam satu lingkaran); lupa mengatur waktu, tetapi butuh sekitar 15 menit untuk membuat file-file itu.

Jalankan yang berikut untuk menghapus file yang dikatakan:

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

100000

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

Ini adalah kotak Pentium 4 2.8GHz (beberapa ratus GB IDE 7200 RPM saya pikir; EXT3). Kernel 2.6.27.

Terkadang Perl dapat bekerja secara ajaib dalam kasus-kasus seperti ini. Sudahkah Anda mencoba jika skrip kecil seperti ini dapat mengungguli bash dan perintah dasar shell?

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

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

Atau yang lain, mungkin pendekatan Perl yang lebih cepat:

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

EDIT: Saya baru saja mencoba skrip Perl saya. Semakin banyak yang melakukan sesuatu dengan benar. Dalam kasus saya, saya mencoba ini dengan server virtual dengan 256 MB RAM dan setengah juta file.

time find /test/directory | xargs rm hasil:

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

dibandingkan dengan

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

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

Dari apa yang saya ingat penghapusan inode dalam sistem file ext adalah O (n ^ 2), sehingga semakin banyak file yang Anda hapus semakin cepat sisanya akan pergi.

Ada satu kali saya dihadapkan dengan masalah yang sama (meskipun perkiraan saya melihat ~ 7h waktu penghapusan), pada akhirnya pergi rute yang disarankan jftuga di komentar pertama .

Yah, ini bukan jawaban yang nyata, tapi ...

Apakah mungkin untuk mengubah filesystem ke ext4 dan melihat apakah ada perubahan?

Baiklah ini telah dibahas dalam berbagai cara di sisa utas tapi saya pikir saya akan membuang dua sen saya. Penyebab kinerja dalam kasus Anda mungkin readdir. Anda mendapatkan kembali daftar file yang tidak selalu berurutan pada disk yang menyebabkan akses disk di semua tempat ketika Anda memutuskan tautan. File-file tersebut cukup kecil sehingga operasi pembatalan tautan mungkin tidak melompat terlalu jauh sehingga ruang kosong. Jika Anda membaca dan kemudian mengurutkan dengan menaik inode Anda mungkin akan mendapatkan kinerja yang lebih baik. Jadi readdir menjadi ram (urutkan berdasarkan inode) -> unlink -> profit.

Inode adalah perkiraan kasar di sini saya pikir .. tetapi mendasarkan pada kasus penggunaan Anda mungkin cukup akurat ...

Saya mungkin akan mengeluarkan kompiler C dan melakukan moral yang setara dengan skrip Anda. Yaitu, gunakan opendir(3)untuk mendapatkan pegangan direktori, kemudian gunakan readdir(3)untuk mendapatkan nama file, lalu menghitung data ketika saya memutuskan tautan dan sesekali cetak "% d file dihapus" (dan mungkin waktu yang berlalu atau cap waktu saat ini).

Saya tidak berharap ini akan terasa lebih cepat daripada versi skrip shell, hanya saja saya terbiasa harus merobek kompiler sekarang dan lagi, baik karena tidak ada cara bersih untuk melakukan apa yang saya inginkan dari shell atau karena sementara bisa dilakukan di shell, itu lambat secara produktif seperti itu.

Anda mungkin mengalami masalah penulisan ulang dengan direktori. Coba hapus file terbaru terlebih dahulu. Lihatlah opsi-opsi mount yang akan menunda writeback ke disk.

Untuk bilah kemajuan coba jalankan sesuatu seperti rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

Inilah cara saya menghapus jutaan file jejak yang kadang-kadang dapat dikumpulkan pada server database Oracle besar:

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

Saya menemukan bahwa ini menghasilkan penghapusan yang cukup lambat yang berdampak rendah pada kinerja server, biasanya sekitar sejam per satu juta file pada pengaturan 10.000 IOPS "khas".

Sering dibutuhkan beberapa menit sebelum direktori dipindai, daftar file awal dibuat dan file pertama dihapus. Dari sana dan seterusnya, a. diulang untuk setiap file yang dihapus.

Keterlambatan yang disebabkan oleh gema ke terminal telah membuktikan cukup penundaan untuk mencegah beban signifikan saat penghapusan sedang berlangsung.

Anda dapat menggunakan fitur paralelisasi '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

sebenarnya, yang ini sedikit lebih baik jika shell yang Anda gunakan melakukan ekspansi baris perintah:

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