rm trên một thư mục có hàng triệu tập tin

Bối cảnh: máy chủ vật lý, khoảng hai năm tuổi, các ổ đĩa SATA 7200-RPM được kết nối với thẻ RAID 3Ware, ext3 FS gắn noatime và dữ liệu = đã đặt hàng, không tải điên, kernel 2.6,18-92.1,22.el5, thời gian hoạt động 545 ngày . Thư mục không chứa bất kỳ thư mục con nào, chỉ có hàng triệu tệp nhỏ (~ 100 byte), với một số tệp lớn hơn (vài KB).

Chúng tôi có một máy chủ đã hoạt động một chút trong vài tháng qua, nhưng chúng tôi chỉ nhận thấy nó vào một ngày khác khi nó bắt đầu không thể ghi vào một thư mục do nó chứa quá nhiều tệp. Cụ thể, nó bắt đầu ném lỗi này trong / var / log / message:

ext3_dx_add_entry: Directory index full!

Đĩa trong câu hỏi có nhiều nút còn lại:

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

Vì vậy, tôi đoán điều đó có nghĩa là chúng ta đạt đến giới hạn số lượng mục có thể có trong tệp thư mục. Không biết có bao nhiêu tệp sẽ có, nhưng nó không thể nhiều hơn, như bạn có thể thấy, hơn ba triệu hoặc hơn thế. Không phải vậy đâu, phiền bạn! Nhưng đó là phần một trong câu hỏi của tôi: chính xác giới hạn trên là gì? Có điều chỉnh được không? Trước khi tôi hét lên, tôi muốn điều chỉnh lại ; thư mục khổng lồ này gây ra tất cả các loại vấn đề.

Dù sao, chúng tôi đã theo dõi vấn đề trong mã đang tạo ra tất cả các tệp đó và chúng tôi đã sửa nó. Bây giờ tôi bị mắc kẹt với việc xóa thư mục.

Một vài lựa chọn ở đây:

1. rm -rf (dir)

   Tôi đã thử điều này đầu tiên. Tôi đã từ bỏ và giết nó sau khi nó chạy được một ngày rưỡi mà không có tác động rõ rệt nào.

2. hủy liên kết (2) trên thư mục: Chắc chắn đáng xem xét, nhưng câu hỏi đặt ra là liệu có thể xóa các tệp trong thư mục qua fsck nhanh hơn so với xóa qua liên kết (2). Đó là, bằng cách này hay cách khác, tôi đã phải đánh dấu các nút đó là không sử dụng. Tất nhiên, điều này giả định rằng tôi có thể nói với fsck không bỏ các mục vào các tệp trong / mất + tìm thấy; mặt khác, tôi vừa chuyển vấn đề của mình Ngoài tất cả các mối quan tâm khác, sau khi đọc về vấn đề này thêm một chút, hóa ra tôi có thể phải gọi một số chức năng FS nội bộ, vì không có biến thể unlink (2) nào tôi có thể tìm thấy sẽ cho phép tôi xóa hoàn toàn một thư mục với các mục trong đó. Pooh.
3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

   Đây thực sự là phiên bản rút gọn; cái thực sự tôi đang chạy, nó chỉ thêm một số báo cáo tiến trình và dừng sạch khi chúng tôi hết tệp để xóa, là:

   xuất i = 0;
   thời gian (trong khi [đúng]; làm
     ls -Uf | đầu -n 3 | grep -qF '.png' || phá vỡ;
     ls -Uf | đầu -n 10000 | xargs rm -f 2> / dev / null;
     xuất i = $ (($ i + 10000));
     tiếng vang "$ i ...";
   làm xong )

   Điều này dường như đang làm việc khá tốt. Khi tôi viết bài này, nó đã xóa 260.000 tệp trong ba mươi phút qua.

1. Như đã đề cập ở trên, giới hạn mục nhập trên mỗi thư mục có thể điều chỉnh?
2. Tại sao phải mất "7m9.561s / người dùng 0m0.001s / sys 0m0.001s" thực sự để xóa một tệp duy nhất là tệp đầu tiên trong danh sách được trả về ls -Uvà phải mất mười phút để xóa 10.000 mục đầu tiên với chỉ huy trong số 3, nhưng bây giờ nó đang di chuyển khá vui vẻ? Đối với vấn đề đó, nó đã xóa 260.000 trong khoảng ba mươi phút, nhưng giờ mất thêm mười lăm phút để xóa thêm 60.000. Tại sao sự thay đổi lớn về tốc độ?
3. Có cách nào tốt hơn để làm điều này không? Không lưu trữ hàng triệu tệp trong một thư mục; Tôi biết điều đó thật ngớ ngẩn, và nó sẽ không xảy ra trên đồng hồ của tôi. Giải quyết vấn đề và xem qua SF và SO cung cấp rất nhiều biến thể về findviệc sẽ không nhanh hơn đáng kể so với cách tiếp cận của tôi vì một số lý do rõ ràng. Nhưng ý tưởng xóa-qua-fsck có chân nào không? Hay cái gì khác hoàn toàn? Tôi rất muốn nghe suy nghĩ ngoài luồng (hoặc bên trong hộp không nổi tiếng).

Đầu ra kịch bản cuối cùng!:

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

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

Vì vậy, ba triệu tệp đã bị xóa trong hơn bốn giờ.

Các data=writebacktùy chọn gắn kết xứng đáng được cố gắng, để ngăn chặn nhật ký của hệ thống tập tin. Điều này chỉ nên được thực hiện trong thời gian xóa, có một rủi ro tuy nhiên nếu máy chủ đang bị tắt hoặc khởi động lại trong quá trình xóa.

Theo trang này ,

Một số ứng dụng cho thấy sự cải thiện tốc độ rất đáng kể khi nó được sử dụng. Ví dụ: có thể thấy sự cải thiện tốc độ (...) khi các ứng dụng tạo và xóa khối lượng lớn các tệp nhỏ.

Tùy chọn được đặt trong fstabhoặc trong khi vận hành gắn kết, thay thế data=orderedbằng data=writeback. Hệ thống tập tin chứa các tập tin sẽ bị xóa phải được tính lại.

Mặc dù nguyên nhân chính của vấn đề này là hiệu suất ext3 với hàng triệu tệp, nguyên nhân gốc thực sự của vấn đề này là khác nhau.

Khi một thư mục cần được liệt kê, readdir () được gọi trên thư mục mang lại danh sách các tệp. readdir là một cuộc gọi posix, nhưng cuộc gọi hệ thống Linux thực sự đang được sử dụng ở đây được gọi là 'getdents'. Getdents liệt kê các mục thư mục bằng cách điền vào một bộ đệm với các mục.

Vấn đề chủ yếu là do readdir () sử dụng kích thước bộ đệm cố định 32Kb để tìm nạp các tệp. Khi một thư mục trở nên lớn hơn và lớn hơn (kích thước tăng khi thêm tệp), ext3 sẽ chậm hơn và chậm hơn để tìm nạp các mục và kích thước bộ đệm 32Kb của readdir bổ sung chỉ đủ để bao gồm một phần của các mục trong thư mục. Điều này khiến readdir lặp đi lặp lại và gọi đi gọi lại hệ thống đắt tiền.

Ví dụ, trên một thư mục thử nghiệm mà tôi đã tạo với hơn 2,6 triệu tệp bên trong, chạy "ls -1 | wc-l" cho thấy một đầu ra bước lớn của nhiều cuộc gọi hệ thống 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
...

Ngoài ra thời gian trong thư mục này là đáng kể.

$ time ls -1 | wc -l
2616044

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

Phương pháp để thực hiện quá trình này hiệu quả hơn là gọi getdents bằng tay với bộ đệm lớn hơn nhiều. Điều này cải thiện hiệu suất đáng kể.

Bây giờ, bạn không nên tự mình gọi getdents để không có giao diện tồn tại để sử dụng bình thường (kiểm tra trang man để xem getdents!), Tuy nhiên, bạn có thể gọi thủ công và làm cho cách gọi hệ thống của bạn hiệu quả hơn.

Điều này làm giảm đáng kể thời gian cần thiết để tìm nạp các tệp này. Tôi đã viết một chương trình làm điều này.

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

Trong khi điều này không chống lại vấn đề cơ bản tiềm ẩn (rất nhiều tệp, trong một hệ thống tệp hoạt động kém ở đó). Nó có thể sẽ nhanh hơn nhiều so với nhiều lựa chọn thay thế được đăng.

Như đã biết trước, người ta nên xóa thư mục bị ảnh hưởng và làm lại sau. Các thư mục chỉ tăng kích thước và có thể vẫn hoạt động kém ngay cả với một vài tệp bên trong do kích thước của thư mục.

Chỉnh sửa: Tôi đã làm sạch điều này khá nhiều. Đã thêm một tùy chọn để cho phép bạn xóa trên dòng lệnh trong thời gian chạy và loại bỏ một loạt các công cụ treewalk, điều mà nhìn lại một cách trung thực là tốt nhất. Cũng được hiển thị để sản xuất tham nhũng bộ nhớ.

Bây giờ bạn có thể làm dentls --delete /my/path

Kết quả mới. Dựa trên một thư mục với 1,82 triệu tệp.

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

Đã loại ngạc nhiên này vẫn hoạt động rất tốt!

Có thể sao lưu tất cả các tệp khác từ hệ thống tệp này vào một vị trí lưu trữ tạm thời, định dạng lại phân vùng và sau đó khôi phục các tệp không?

Không có giới hạn tệp thư mục trong ext3 chỉ giới hạn inode của hệ thống tệp (tôi nghĩ rằng có giới hạn về số lượng thư mục con mặc dù).

Bạn vẫn có thể gặp vấn đề sau khi gỡ bỏ các tập tin.

Khi một thư mục có hàng triệu tệp, mục nhập thư mục sẽ trở nên rất lớn. Mục nhập thư mục phải được quét cho mọi thao tác xóa và mất nhiều thời gian khác nhau cho mỗi tệp, tùy thuộc vào vị trí của mục nhập. Thật không may, ngay cả sau khi tất cả các tệp đã bị xóa, mục nhập thư mục vẫn giữ nguyên kích thước của nó. Vì vậy, các hoạt động tiếp theo yêu cầu quét mục nhập thư mục sẽ vẫn mất nhiều thời gian ngay cả khi thư mục hiện đang trống. Cách duy nhất để giải quyết vấn đề đó là đổi tên thư mục, tạo một cái mới với tên cũ và chuyển bất kỳ tệp nào còn lại sang cái mới. Sau đó xóa cái đã đổi tên.

Tôi đã không điểm chuẩn nó, nhưng anh chàng này đã làm :

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

Tìm đơn giản là không hoạt động đối với tôi, ngay cả sau khi thay đổi các tham số của ext3 fs theo đề xuất của người dùng ở trên. Tiêu thụ quá nhiều bộ nhớ. Kịch bản PHP này đã thực hiện thủ thuật - sử dụng CPU nhanh, không đáng kể, sử dụng bộ nhớ không đáng kể:

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

Tôi đã đăng một báo cáo lỗi liên quan đến rắc rối này với find: http://savannah.gnu.org/bugs/?31961

Gần đây tôi đã gặp phải một vấn đề tương tự và không thể làm cho data=writebackđề xuất của ring0 hoạt động (có thể do thực tế là các tệp nằm trên phân vùng chính của tôi). Trong khi nghiên cứu cách giải quyết, tôi tình cờ phát hiện ra điều này:

tune2fs -O ^has_journal <device>

Điều này sẽ tắt nhật ký hoàn toàn, bất kể datatùy chọn đưa ra mount. Tôi đã kết hợp điều này với noatimevà âm lượng đã được dir_indexthiết lập, và nó dường như hoạt động khá tốt. Việc xóa thực sự kết thúc mà tôi không cần phải giết nó, hệ thống của tôi vẫn phản hồi và hiện đã sao lưu và chạy (với nhật ký trở lại) mà không gặp vấn đề gì.

Hãy chắc chắn rằng bạn làm:

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

mà nên tăng tốc mọi thứ lên một chút là tốt.

Lệnh rất chậm. Thử:

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

Được dir_indexđặt cho hệ thống tập tin? ( tune2fs -l | grep dir_index) Nếu không, kích hoạt nó. Nó thường được bật cho RHEL mới.

Vài năm trước, tôi tìm thấy một thư mục chứa 16 triệu tệp XML trong /hệ thống tệp. Do sự nghiêm trọng của máy chủ, chúng tôi đã sử dụng lệnh sau mất khoảng 30 giờ để hoàn thành:

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

Đó là một hdd 7200 vòng / phút cũ , và mặc dù tắc nghẽn IO và CPU tăng đột biến, máy chủ web cũ vẫn tiếp tục dịch vụ của mình.

Tùy chọn ưa thích của tôi là cách tiếp cận newfs, đã được đề xuất. Vấn đề cơ bản là, một lần nữa như đã lưu ý, quét tuyến tính để xử lý xóa là có vấn đề.

rm -rfnên gần tối ưu cho một hệ thống tập tin cục bộ (NFS sẽ khác). Nhưng với hàng triệu tệp, 36 byte cho mỗi tên tệp và 4 cho mỗi nút (một phỏng đoán, không kiểm tra giá trị cho ext3), đó là 40 * triệu, được giữ trong RAM chỉ dành cho thư mục.

Theo phỏng đoán, bạn đang sử dụng bộ nhớ đệm siêu dữ liệu của hệ thống tệp trong Linux, do đó, các khối cho một trang của tệp thư mục sẽ bị hết hạn trong khi bạn vẫn đang sử dụng một phần khác, chỉ để nhấn lại trang đó của bộ đệm khi tiếp theo tập tin bị xóa Điều chỉnh hiệu suất Linux không phải là khu vực của tôi, nhưng / Proc / sys / {vm, fs} / có thể chứa một cái gì đó có liên quan.

Nếu bạn có thể đủ khả năng ngừng hoạt động, bạn có thể xem xét bật tính năng dir_index. Nó chuyển chỉ mục thư mục từ tuyến tính sang thứ gì đó tối ưu hơn nhiều để xóa trong các thư mục lớn (b-cây băm). tune2fs -O dir_index ...tiếp theo e2fsck -Dsẽ làm việc. Tuy nhiên, mặc dù tôi tin rằng điều này sẽ giúp ích trước khi có vấn đề, tôi không biết cách chuyển đổi (e2fsck với -D) thực hiện khi xử lý thư mục v.lund hiện có. Sao lưu + mút nó và xem.

Rõ ràng không phải táo để táo ở đây, nhưng tôi thiết lập một thử nghiệm nhỏ và làm như sau:

Tạo 100.000 tệp 512 byte trong một thư mục ( ddvà /dev/urandomtrong một vòng lặp); quên thời gian, nhưng mất khoảng 15 phút để tạo các tệp đó.

Chạy các mục sau để xóa các tệp đã nói:

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

100000

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

Đây là hộp Pentium 4 2.8GHz (tôi nghĩ vài trăm GB IDE 7200 RPM; EXT3). Hạt nhân 2.6.27.

Đôi khi Perl có thể làm việc kỳ diệu trong những trường hợp như thế này. Bạn đã thử nếu một tập lệnh nhỏ như thế này có thể vượt trội hơn bash và các lệnh shell cơ bản chưa?

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

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

Hoặc cách khác, có lẽ còn nhanh hơn, cách tiếp cận Perl:

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

EDIT: Tôi vừa thử kịch bản Perl của mình. Càng dài càng làm một cái gì đó đúng. Trong trường hợp của tôi, tôi đã thử điều này với một máy chủ ảo có RAM 256 MB và nửa triệu tệp.

time find /test/directory | xargs rm các kết quả:

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

so với

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

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

Từ những gì tôi nhớ, việc xóa các nút trong hệ thống tập tin ext là O (n ^ 2), do đó, càng nhiều tệp bạn xóa thì phần còn lại sẽ càng nhanh.

Có một lần tôi đã phải đối mặt với vấn đề tương tự (mặc dù ước tính của tôi đã xem xét thời gian xóa ~ 7h), cuối cùng đã đi theo lộ trình đề xuất jftuga trong bình luận đầu tiên .

Chà, đây không phải là một câu trả lời thực sự, nhưng ...

Có thể chuyển đổi hệ thống tập tin thành ext4 và xem nếu mọi thứ thay đổi?

Được rồi, điều này đã được trình bày theo nhiều cách khác nhau trong phần còn lại của chủ đề nhưng tôi nghĩ rằng tôi sẽ ném vào hai xu của mình. Thủ phạm hiệu suất trong trường hợp của bạn có lẽ là readdir. Bạn đang nhận lại một danh sách các tệp không nhất thiết phải theo thứ tự trên đĩa, điều này gây ra sự truy cập đĩa khắp nơi khi bạn hủy liên kết. Các tệp đủ nhỏ để thao tác hủy liên kết có thể không nhảy quá nhiều khoảng trống. Nếu bạn readdir và sau đó sắp xếp theo inode tăng dần, bạn có thể sẽ có hiệu suất tốt hơn. Vì vậy, readdir vào ram (sắp xếp theo inode) -> hủy liên kết -> lợi nhuận.

Inode là một xấp xỉ thô ở đây tôi nghĩ rằng .. nhưng dựa trên trường hợp sử dụng của bạn, nó có thể khá chính xác ...

Tôi có thể đã đánh cắp trình biên dịch C và thực hiện tương đương đạo đức với kịch bản của bạn. Đó là, sử dụng opendir(3)để có được một thư mục xử lý, sau đó sử dụng readdir(3)để lấy tên của các tệp, sau đó kiểm tra các tệp khi tôi hủy liên kết chúng và thỉnh thoảng in "% d các tệp đã bị xóa" (và có thể là thời gian trôi qua hoặc dấu thời gian hiện tại).

Tôi không hy vọng nó sẽ nhanh hơn đáng kể so với phiên bản shell script, chỉ là tôi đã từng phải sử dụng trình biên dịch hết lần này đến lần khác, bởi vì không có cách nào rõ ràng để làm những gì tôi muốn từ shell hoặc bởi vì trong khi có thể thực hiện được trong vỏ, nó không hiệu quả làm chậm theo cách đó.

Bạn có khả năng chạy vào các vấn đề viết lại với thư mục. Hãy thử xóa các tập tin mới nhất trước. Nhìn vào các tùy chọn gắn kết sẽ trì hoãn ghi vào đĩa.

Đối với thanh tiến trình, hãy thử chạy một cái gì đó như rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

Đây là cách tôi xóa hàng triệu tệp theo dõi đôi khi có thể thu thập trên một máy chủ cơ sở dữ liệu Oracle lớn:

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

Tôi thấy rằng điều này dẫn đến việc xóa khá chậm, ảnh hưởng đến hiệu suất máy chủ thấp, thường là một thứ gì đó trong một giờ trên một triệu tệp trên thiết lập 10.000 IOPS "điển hình".

Nó thường sẽ mất vài phút trước khi các thư mục được quét, danh sách tệp ban đầu được tạo và tệp đầu tiên bị xóa. Từ đó trở đi, a. được lặp lại cho mỗi tập tin bị xóa.

Sự chậm trễ gây ra bởi tiếng vang đến thiết bị đầu cuối đã chứng minh đủ độ trễ để ngăn chặn bất kỳ tải đáng kể nào trong khi quá trình xóa đang diễn ra.

Bạn có thể sử dụng các tính năng song song của '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

thực tế, cái này tốt hơn một chút nếu shell bạn sử dụng không mở rộng dòng lệnh:

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