milyonlarca dosya içeren bir dizindeki rm

Arka plan: Fiziksel sunucu, yaklaşık iki yaşında, 3Ware RAID karta bağlı 7200 RPM SATA sürücüler, ext3 FS'ye monte edilmiş bir zaman dilimi ve veri = sipariş edildi, çılgın yük altında değil, çekirdek 2.6.18-92.1.22.el5, çalışma süresi 545 gün . Dizin, daha büyük (birkaç KB) dosya içeren milyonlarca küçük (~ 100 byte) dosya içeren herhangi bir alt dizin içermez.

Son birkaç ay boyunca biraz guguklandıran bir sunucumuz var, ancak geçen gün sadece çok fazla dosya içerdiği için bir dizine yazamaya başladığını fark ettik. Özellikle, bu hatayı / var / log / messages içine atmaya başladı:

ext3_dx_add_entry: Directory index full!

Söz konusu diskte kalan çok sayıda düğüm var:

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

Dolayısıyla, bunun dizin dosyasında kaç giriş olabileceğinin sınırına ulaştığımız anlamına geldiğini tahmin ediyorum. Ne kadar dosya olacağı hakkında hiçbir fikrim yok, ancak görebileceğiniz gibi, üç milyondan fazla olamaz. Bu iyi değil, dikkat et! Ama bu sorumun bir parçası: tam olarak bu üst sınır nedir? Ayarlanabilir mi? Ben bağırdı önce at-ı ayar bunu istiyorum aşağı ; Bu devasa dizin her türlü soruna yol açtı.

Neyse, tüm bu dosyaları oluşturan koddaki sorunu tespit ettik ve düzelttik. Şimdi dizini silmeme şaşırdım.

Burada birkaç seçenek:

1. rm -rf (dir)

   Bunu önce denedim. Kesin bir etkisi olmadan bir buçuk gün çalıştıktan sonra pes ettim ve onu öldürdüm.

2. Dizinde unlink (2): Kesinlikle dikkate değer, ancak soru, fsck ile dizindeki dosyaları silmenin unlink (2) ile silmekten daha hızlı olup olmayacağıdır. Yani, öyle ya da böyle, bu düğümleri kullanılmamış olarak işaretlemeliyim. Bu, elbette fsck’e girişleri / kayıp + bulunan dosyalara bırakmamasını söyleyebilir; Aksi takdirde, sorunumu yeni çözdüm. Diğer tüm kaygılara ek olarak, bu konuyu biraz daha okuduktan sonra, bulabileceğim unlink (2) türevlerinin hiçbiri sadece blithly silmeme izin vermeyeceğinden muhtemelen bazı iç FS işlevlerini çağırmak zorunda kalacağım ortaya çıktı. girişleri olan bir dizin. Pooh.
3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

   Bu aslında kısaltılmış versiyonu; Çalıştırmakta olduğum gerçek, sadece biraz ilerleme bildiren ve silmek için dosyalarımız bittiğinde temiz bir durma sağlayan:

   ihracat i = 0;
   zaman (iken [gerçek]; yap
     ls -Uf | kafa -n 3 | grep -qF '.png' || break;
     ls -Uf | kafa -n 10000 | xargs rm -f2> / dev / null;
     dışa aktarma i = $ (($ i + 10000));
     echo "$ i ...";
   bitti)

   Bu oldukça iyi çalışıyor gibi görünüyor. Bunu yazarken, son otuz dakika içinde 260.000 dosyayı silmiş.

1. Yukarıda belirtildiği gibi, dizin başına giriş sınırı ayarlanabilir mi?
2. Listenin başında gelen ilk dosya olan tek bir dosyayı silmek neden "gerçek 7m9.561s / kullanıcı 0m0.001s / sys 0m0.001s" ls -Ualdı ve ilk 10.000 girişi silmek Komuta # 3'te, ama şimdi oldukça mutlu bir şekilde hareket ediyor mu? Bu nedenle, yaklaşık otuz dakikada 260.000 sildi, ancak şimdi 60.000 daha fazla silmek için on beş dakika daha sürdü. Neden dev hızda sallanıyor?
3. Böyle bir şey yapmanın daha iyi bir yolu var mı? Bir dizinde milyonlarca dosya saklamayın; Aptalca olduğunu biliyorum ve saatimde olmazdı. Sorunun googling edilmesi ve SF ve SO'lara findbakılması, bazı belirgin nedenlerden dolayı benim yaklaşımımdan önemli ölçüde daha hızlı olmayacak birçok değişiklik sunar . Ancak fsck yoluyla silme fikrinin herhangi bir ayağı var mı? Ya da tamamen başka bir şey? Kutudan çıkma (ya da tanınmayan kutunun içi) düşüncesini duymak için sabırsızlanıyorum.

Son senaryo çıktısı !:

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

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

Böylece, üç milyon dosya dört saatten biraz daha fazla bir sürede silindi.

data=writebackMontaj opsiyonu dosya sisteminin günlük kaydını engellemek için, denenmiş hak ediyor. Bu sadece silme süresi içerisinde yapılmalıdır, silme işlemi sırasında sunucunun kapatılması veya yeniden başlatılması durumunda bir risk vardır.

Göre bu sayfada ,

Bazı uygulamalar kullanıldığında çok önemli bir hız artışı göstermektedir. Örneğin, uygulamalar büyük hacimlerde küçük dosyalar oluştururken ve silerken hız iyileştirmeleri görülebilir (...).

Seçeneği ya ayarlanır fstabdeğiştirme veya bağlama işlemi sırasında data=orderedile data=writeback. Silinecek dosyaları içeren dosya sistemi yeniden kurulmalıdır.

Bu sorunun asıl nedeni milyonlarca dosyayla ext3 performansı olsa da, bu sorunun asıl kök nedeni farklıdır.

Bir dizinin listelenmesi gerektiğinde, dosyaların listesini veren dizinde readdir () çağrılır. readdir bir posix çağrısıdır, ancak burada kullanılan gerçek Linux sistem çağrısı 'getdents' olarak adlandırılır. Getdents dizinleri girişleri arabellekleri girişlerle doldurarak listeler.

Sorun temel olarak, readdir () öğesinin dosyaları almak için 32Kb sabit arabellek boyutu kullanmasından kaynaklanmaktadır. Bir dizin büyüdükçe ve büyüdükçe (dosyalar eklendikçe boyut artar) ext3 girişleri almak için yavaşlar ve yavaşlar ve ek readdir'in 32Kb arabellek boyutu yalnızca dizine girdilerin bir kısmını eklemek için yeterlidir. Bu, readdir'in tekrar tekrar dönmesine ve tekrar tekrar pahalı sistem çağrısını çağırmasına neden olur.

Örneğin, içinde 2.6 milyondan fazla dosyayla oluşturduğum bir test dizininde, "ls -1 | wc-l" nin çalıştırılması birçok getdent sistem çağrısının büyük bir çekici çıktısını gösterir.

$ 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
...

Ek olarak, bu dizinde harcanan zaman önemliydi.

$ time ls -1 | wc -l
2616044

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

Bunu daha verimli bir işlem haline getirmenin yöntemi getdents'i daha büyük bir tamponla manuel olarak çağırmaktır. Bu, performansı önemli ölçüde artırır.

Şimdi, kendinizi elle hiçbir arayüzü normal kullanmak için var getdents aramak gerekmiyor (görmek getdents man sayfasına bakın!), Ancak yapabilirsiniz elle arayıp sistem çağrısı çağırma yol daha verimli hale getirir.

Bu, bu dosyaların alınması için gereken süreyi büyük ölçüde azaltır. Bunu yapan bir program yazdım.

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

Bu, temel problemle (kötü performans gösteren bir dosya sisteminde çok sayıda dosyayla) savaşmaz. Gönderilecek alternatiflerin çoğundan çok, çok daha hızlı olması muhtemeldir.

Öngörü olarak, kişi etkilenen dizini silmeli ve sonra yeniden düzenlemelidir. Dizinler yalnızca boyut olarak çoğalır ve dizinin boyutu nedeniyle içinde bulunan birkaç dosyada bile düşük performans göstermeye devam eder.

Düzenleme: Bu biraz temizledik. Çalışma zamanında komut satırından silmenize izin veren bir seçenek eklendi ve dürüstçe geriye bakıldığında en iyi şekilde sorgulanabilecek bir grup treewalk maddesini kaldırın. Ayrıca hafıza bozulmasına yol açtığı da gösterildi.

Şimdi yapabilirsin dentls --delete /my/path

Yeni sonuçlar 1,82 milyon dosya içeren bir dizinden alınmıştır.

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

Bu hala çok iyi çalıştığını şaşırttı!

Diğer tüm dosyaları bu dosya sisteminden geçici bir depolama konumuna yedeklemek, bölümü yeniden biçimlendirmek ve ardından dosyaları geri yüklemek mümkün müdür?

Sadece dosya sistemi inode limitinin ext3'te dizin başına dosya sınırı yoktur (sanırım alt dizinlerin sayısında bir sınır olduğunu düşünüyorum).

Dosyaları kaldırdıktan sonra hala sorunlarınız olabilir.

Bir dizin milyonlarca dosyaya sahip olduğunda, dizin girişinin kendisi çok büyük olur. Dizin girişi her kaldırma işlemi için taranmalıdır ve girişin bulunduğu yere bağlı olarak her dosya için çeşitli süreler gerekir. Ne yazık ki, tüm dosyalar kaldırıldıktan sonra bile, dizin girişi boyutunu korur. Bu nedenle, dizin girişinin taranmasını gerektiren diğer işlemler, dizin boş olsa bile hala uzun zaman alacaktır. Bu sorunu çözmenin tek yolu dizini yeniden adlandırmak, eski adıyla yeni bir tane oluşturmak ve kalan dosyaları yenisine aktarmaktır. Sonra yeniden adlandırılmış olanı silin.

Ben kıyaslamadım, ama bu adam yaptı :

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

ext3 fs'in parametrelerini yukarıdaki kullanıcılar tarafından önerilen şekilde değiştirdikten sonra bile, bul, benim için işe yaramadı. Tüketilen yol çok fazla hafıza. Bu PHP betiği hile - hızlı, önemsiz CPU kullanımı, önemsiz bellek kullanımı:

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

Bu sorunla ilgili bir hata raporu buldum: http://savannah.gnu.org/bugs/?31961

Geçenlerde benzer bir sorunla karşı karşıya kaldım ve ring0’in data=writebackçalışma önerisini alamadım (muhtemelen dosyalar benim ana bölümümde olduğu için). Geçici çözümler araştırırken bunun üzerine düştüm:

tune2fs -O ^has_journal <device>

Bu, dataseçeneğin ne olduğuna bakılmaksızın günlük kaydını tamamen kapatır mount. Bunu birleştirdim noatimeve ses dir_indexayarlanmış ve oldukça iyi çalışıyor gibiydi. Silme aslında onu öldürme gereği duymadan bitti, sistemim yanıt vermeye devam etti ve şimdi sorunsuz bir şekilde çalışmaya devam ediyor.

Yaptığınızdan emin olun:

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

Bu da işleri biraz hızlandırmalı.

Çok yavaş bir emir. Deneyin:

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

dir_indexDosya sistemi için ayarlandı mı ? ( tune2fs -l | grep dir_index) Değilse, etkinleştirin. Genellikle yeni RHEL için açık.

Birkaç yıl önce, dosya sisteminde 16 milyon XML dosyası bulunan bir dizin buldum /. Sunucunun eleştirisi nedeniyle bitirilmesi yaklaşık 30 saat süren aşağıdaki komutu kullandık :

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

Eski bir 7200 rpm hdd idi ve IO darboğazına ve CPU artışlarına rağmen, eski web sunucusu hizmetine devam etti.

Tercih ettiğim seçenek, daha önce önerilmiş olan newfs yaklaşımı. Temel problem, daha önce de belirtildiği gibi, silme işlemine yönelik doğrusal taramanın sorunlu olmasıdır.

rm -rfYerel bir dosya sistemi için en uygun yere yakın olmalıdır (NFS farklı olacaktır). Ancak milyonlarca dosyada, dosya adı başına 36 bayt ve inode başına 4 (tahmin, ext3 değerini kontrol etmiyor), bu sadece dizin için RAM'de tutulacak 40 * milyon.

Tahmin ediyorum ki, Linux'ta dosya sistemi meta veri önbellek belleğine çarpıyorsunuz, böylece yine de başka bir parça kullanırken dizin dosyasının bir sayfasının blokları atılıyor, yalnızca bir dahaki sefere önbelleğin o sayfasına tekrar basmak için dosya silindi. Linux performans ayarı benim alanım değil, ancak / proc / sys / {vm, fs} / muhtemelen alakalı bir şeyler içeriyor.

Arıza süresi karşılayabiliyorsanız, dir_index özelliğini açmayı düşünebilirsiniz. Dizin endeksini büyük dizinlerde (karma ağaçlarda) silmek için doğrusaldan çok daha uygun bir şeye geçirir. tune2fs -O dir_index ...ardından e2fsck -Dişe yarardı. Bununla birlikte, sorun çıkmadan önce bunun yardımcı olacağından emin olmakla birlikte, -Dmevcut bir v.large diziniyle çalışırken dönüşümün (e2fsck) ile nasıl çalıştığını bilmiyorum . Yedekler + em ve gör.

Belli ki burada elmalar için elmalar yok, fakat küçük bir test yaptım ve şunları yaptım:

Bir dizinde ( ddve /dev/urandombir döngüde) 100.000 512 bayt dosya oluşturuldu ; Zamanında unuttum, ancak bu dosyaları oluşturmak için yaklaşık 15 dakika sürdü.

Söz konusu dosyaları silmek için aşağıdakileri çalıştırın:

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

100000

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

Bu bir Pentium 4 2.8GHz kutusudur (birkaç yüz GB IDE 7200 RPM sanırım; EXT3). Çekirdek 2.6.27.

Perl bazen böyle durumlarda harikalar yaratabilir. Böyle küçük bir betiğin bash ve temel kabuk komutlarından daha iyi performans gösterip göstermediğini zaten denediniz mi?

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

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

Ya da başka bir, belki daha hızlı, Perl yaklaşıyor:

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

EDIT: Ben sadece Perl scriptlerimi bir deneyin. Daha ayrıntılı olanı doğru bir şey yapar. Benim durumumda bunu 256 MB RAM ve yarım milyon dosya içeren sanal bir sunucu ile denedim.

time find /test/directory | xargs rm Sonuçlar:

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

nazaran

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

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

Eklenti dosya sistemindeki inode'ların silinmesini hatırladığım kadarıyla O (n ^ 2), yani ne kadar çok silerseniz o kadar hızlı gidersiniz.

Bir kez benzer bir sorunla karşı karşıya kaldım (tahminlerim ~ 7 saat silme zamanına baksa da), sonunda ilk yorumu yapılan jftuga önerilen rotaya gitti .

Bu gerçek bir cevap değil ama ...

Dosya sistemini ext4'e dönüştürmek ve işlerin değişip değişmediğini görmek mümkün müdür?

Tamam, bu iş parçacığının geri kalanında çeşitli şekillerde ele alındı, ancak iki sentimi de atabileceğimi düşündüm. Davanızdaki performans suçlusu muhtemelen okundu. Bağlantıyı kaldırdığınızda her yere disk erişimine neden olan disk üzerinde sıralı bir şekilde olması gerekmeyen dosyaların bir listesini geri alıyorsunuz. Dosyalar, unlink işleminin büyük olasılıkla boşluğu sıfırlayarak atlamamaya yetecek kadar küçüktür. Okudunuz ve sonra artan inode'a göre sıralarsanız, muhtemelen daha iyi performans elde edersiniz. Yani ram içine readdir (inode'a göre sırala) -> unlink -> kar.

Inode burda kaba bir yaklaşım. Sanırım .. ama kullanım durumunuza dayanarak oldukça doğru olabilir ...

Muhtemelen bir C derleyicisini çırpmış ve betiğinizin ahlaki eşdeğerini yapmış olurdum. Diğer bir deyişle, opendir(3)bir dizin tanıtıcısı readdir(3)almak için kullanın, sonra dosyaların adını almak için kullanın , sonra da bağlantılarını açtıklarında dosyaları toparlayın ve arada bir "% d dosya silindi" (ve muhtemelen geçen zaman veya geçerli zaman damgası) yazdırın.

Kabuk betiği versiyonundan belirgin bir şekilde daha hızlı olmasını beklemiyorum, sadece derleyiciyi şimdi ve tekrar sökmek zorunda kalmam gerektiğinden, çünkü kabuğundan istediklerimi temiz bir şekilde yapmamın nedeni ya da çünkü kabuklu yapılabilirken, bu şekilde verimsiz yavaşlar.

Muhtemelen dizinde yeniden yazım sorunlarıyla karşılaşıyorsunuzdur. Önce en yeni dosyaları silmeyi deneyin. Diske geri yazma işlemini geciktirecek takma seçeneklerine bakın.

Bir ilerleme çubuğu için gibi bir şey çalıştırmayı deneyin rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

Bazen büyük bir Oracle veritabanı sunucusunda toplanabilecek milyonlarca izleme dosyasını nasıl sildiğim:

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

Bunun, "tipik" 10.000 IOPS kurulumunda genellikle milyonda bir saatlik bir satır boyunca olan sunucu performansı üzerinde düşük etkiye sahip oldukça yavaş bir silme ile sonuçlandığını buluyorum.

Dizinlerin taranması, ilk dosya listesi oluşturulmuş ve ilk dosya silinmesi genellikle birkaç dakika alacaktır. Oradan ve oradan, bir. silinen her dosya için yankılanır.

Terminale yankılanmanın gecikmesi, silme işlemi devam ederken herhangi bir önemli yükü önlemek için yeterli bir gecikme olduğunu kanıtlamıştır.

'Xargs' paralelleştirme özelliklerini kullanabilirsiniz:

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

Aslında, kullandığınız kabuk komut satırı genişletme yaparsa bu biraz daha iyidir:

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