Làm thế nào để làm cho `rm` nhanh hơn trên ext3 / linux?

Tôi có hệ thống tập tin ext3 gắn với các tùy chọn mặc định. Trên đó tôi có một số tập tin ~ 100GB.

Việc xóa bất kỳ tệp nào như vậy sẽ mất nhiều thời gian (8 phút) và gây ra nhiều lưu lượng io, làm tăng tải trên máy chủ.

Có cách nào để làm cho rm không gây rối?

Câu trả lời thú vị nhất ban đầu được chôn trong một bình luận về câu hỏi. Đây là câu trả lời hạng nhất để làm cho nó rõ hơn:

Về cơ bản không có phương pháp nào từ đây hoạt động, vì vậy chúng tôi đã phát triển riêng của chúng tôi. Mô tả nó ở đây: http://www.depesz.com/index.php/2010/04/04/how-to-remove-backups/ - depesz ngày 6 tháng 4, 10 lúc 15:15

Liên kết đó là một phân tích cực kỳ kỹ lưỡng về thăm dò và khám phá một giải pháp khả thi.

Cũng lưu ý:

Bài báo nói:

Như bạn có thể thấy, tôi đã sử dụng -c2 -n7các tùy chọn để ionice, có vẻ lành mạnh.

đó là sự thật, nhưng người dùng TafT nói rằng nếu bạn không muốn bị gián đoạn thì -c3'nhàn rỗi' sẽ là lựa chọn tốt hơn -c2'nỗ lực tốt nhất'. Ông đã sử dụng -c3để xây dựng trong nền và đã tìm thấy nó hoạt động tốt mà không khiến cho việc xây dựng phải chờ đợi mãi mãi. Nếu bạn thực sự có 100% sử dụng io thì -c3sẽ không cho phép xóa hoàn thành nhưng anh ta không mong đợi đó là những gì bạn có dựa trên bài kiểm tra đã làm việc.

Nâng cấp lên ext4 hoặc một số hệ thống tập tin hiện đại khác sử dụng phạm vi. Vì ext3 sử dụng sơ đồ khối gián tiếp thay vì phạm vi, nên việc xóa các tệp lớn chắc chắn sẽ đòi hỏi rất nhiều công việc.

Bạn có thể thử ionice . Nó sẽ không làm cho nó nhanh hơn nhưng nó có thể làm cho nó ít gây rối hơn.

Về hiệu quả, sử dụng một rm cho mỗi tệp là không tối ưu, vì nó yêu cầu một ngã ba và thực thi cho mỗi rm.

Giả sử bạn có một list.txt chứa các tệp bạn muốn xóa thì việc này sẽ hiệu quả hơn nhưng nó vẫn sẽ chậm:

xargs -i rm {} < list.txt

Một cách tiếp cận khác là: nice -20 xargs -i rm {} < list.txt
(việc này sẽ tốn ít thời gian hơn nhưng sẽ ảnh hưởng lớn đến hệ thống của bạn :)

hoặc là

Tôi không biết điều này sẽ nhanh như thế nào nhưng:

mv <file-name> /dev/null 

hoặc là

Tạo một điểm gắn kết đặc biệt với hệ thống tệp nhanh (sử dụng thiết bị lặp?), Sử dụng điểm đó để lưu trữ và xóa các tệp khổng lồ của bạn.
(có thể di chuyển các tệp ở đó trước khi bạn xóa chúng, có thể nhanh hơn hoặc có thể chỉ ngắt kết nối khi bạn muốn các tệp biến mất)

hoặc là

cat /dev/null > /file/to/be/deleted(vì vậy bây giờ nó có kích thước bằng 0) và nếu bạn muốn nó biến mất ngay rm -rf <file>bây giờ

hoặc thậm chí tốt hơn

thả con mèo và làm # > /file/to/be/emptied

Tôi gặp vấn đề với việc xóa thư mục với tốc độ hợp lý, hóa ra quá trình đã khóa đĩa và tạo ra một đống các quá trình cố gắng truy cập vào đĩa. ionice không hoạt động, nó chỉ tiếp tục sử dụng 99% IO của đĩa và khóa tất cả các quy trình khác.

Đây là mã Python làm việc cho tôi. Nó xóa 500 tệp cùng một lúc, sau đó nghỉ 2 giây để cho các quá trình khác thực hiện công việc của mình, sau đó tiếp tục. Công trình tuyệt vời.

import os, os.path
import time

for root, dirs, files in os.walk('/dir/to/delete/files'):
    file_num = 0
    for f in files:
        fullpath = os.path.join(root, f)
        os.remove(fullpath)
        if file_num%500 == 1:
            time.sleep(2)
            print "Deleted %i files" % file_num
        file_num = file_num + 1

Hai xu của tôi.

Tôi đã có vấn đề này. "Trong tập lệnh tuần tự phải chạy nhanh, quá trình loại bỏ rất nhiều tập tin" .. Vì vậy, "rm" sẽ làm cho tập lệnh đó có tốc độ gần với thời gian chờ / thực thi IO.

Vì vậy, để làm cho mọi thứ nhanh hơn, tôi đã thêm một quy trình khác (bash script) được khởi chạy cho mỗi cron .. giống như một trình thu gom rác, nó xóa tất cả các tệp trong một thư mục cụ thể.

Sau đó, tôi đã cập nhật tập lệnh gốc bằng cách thay thế "rm" bằng mv thành "thư mục rác" (đổi tên tệp bằng cách thêm bộ đếm ở cuối tên của nó để tránh xung đột).

Điều này làm việc cho tôi, kịch bản chạy nhanh hơn ít nhất 3 lần. nhưng nó chỉ hoạt động tốt nếu thư mục rác và tệp gốc nằm dưới cùng một điểm gắn kết (cùng thiết bị) để tránh sao chép tệp. (mv trên cùng một thiết bị tiêu thụ ít IO hơn rm)

Mong rằng sẽ giúp ..

Cũng lưu ý rằng câu trả lời của Dennis Williamson, người gợi ý ionice như một cách giải quyết cho tải, sẽ chỉ hoạt động nếu thiết bị khối của bạn sử dụng bộ lập lịch CFQ io.

Bạn có thể thử tạo một hệ thống tệp vòng lặp để lưu trữ các bản sao lưu của mình.

# dd if=/dev/zero of=/path/to/virtualfs bs=100M count=1024 # 100 MB * 1024 = 100 GB
# mke2fs /path/to/virtualfs
# mount -t ext2 /path/to/virtualfs /mnt/backups -o loop

Sau đó, khi bạn muốn xóa các bản sao lưu:

# umount /mnt/backups
# mke2fs /path/to/virtualfs
# mount -t ext2 /path/to/virtualfs /mnt/backups -o loop

Mau! Toàn bộ hệ thống tập tin ảo bị xóa trong vài phút.

Bạn có thể sử dụng xiths đa luồng

find . -type f | xargs -P 30 rm -rf 

Trong đó 30 là số lượng chủ đề mà bạn muốn tạo. Nếu bạn đang sử dụng zero, hệ thống sẽ tạo các luồng tối đa có sẵn cho người dùng thực thi tác vụ.

mv <tên tệp> / dev / null

/ dev / null là một tập tin không phải là một thư mục. Không thể di chuyển một tập tin, đến một tập tin, hoặc bạn có nguy cơ ghi đè lên nó.

Tạo một điểm gắn kết đặc biệt với hệ thống tệp nhanh (sử dụng thiết bị lặp?), Sử dụng điểm đó để lưu trữ và xóa các tệp khổng lồ của bạn. (có thể di chuyển các tệp ở đó trước khi bạn xóa chúng, có thể nhanh hơn hoặc có thể chỉ ngắt kết nối khi bạn muốn các tệp biến mất)

Tôi không nghĩ rằng điều này là thực tế. Nó sẽ sử dụng I / O nhiều hơn một cách không cần thiết so với OP muốn.

/ dev / null là một tập tin không phải là một thư mục. Không thể di chuyển một tập tin, đến một tập tin, hoặc bạn có nguy cơ ghi đè lên nó.

Trên thực tế, đó là một thiết bị và tất cả dữ liệu được ghi vào thiết bị sẽ bị loại bỏ vì vậy mv <file> /dev/nullcó ý nghĩa

Từ Wikipedia, bách khoa toàn thư miễn phí
Trong các hệ điều hành giống Unix, / dev / null hoặc thiết bị null là một tệp đặc biệt loại bỏ tất cả dữ liệu được ghi vào nó (nhưng báo cáo rằng hoạt động ghi đã thành công) và không cung cấp dữ liệu cho bất kỳ quy trình nào đọc từ nó (thu được EOF ngay lập tức). [1]