Làm cách nào để loại bỏ cây con (`rm -rf`) khỏi bỏ đói các quy trình khác cho Đĩa I / O?


8

Chúng tôi có một thư mục bộ đệm Nginx rất lớn (nhiều GB) cho một trang web bận rộn, đôi khi chúng tôi cần phải xóa tất cả cùng một lúc. Tôi đã giải quyết điều này trong quá khứ bằng cách di chuyển thư mục bộ đệm sang một đường dẫn mới, tạo một thư mục bộ đệm mới ở đường dẫn cũ và sau đó rm -rflấy thư mục bộ đệm cũ.

Tuy nhiên, gần đây, khi tôi cần xóa bộ nhớ cache vào một buổi sáng bận rộn, I / O từ đó rm -rfđang bỏ đói các quá trình truy cập đĩa của máy chủ của tôi, vì cả Nginx và máy chủ mà nó hướng tới đều đọc được. Tôi có thể xem mức tăng trung bình của tải trong khi CPU không hoạt động và rm -rfchiếm 98-99% của Đĩa IO iotop.

Tôi đã thử ionice -c 3khi gọi rm, nhưng dường như không có tác dụng đáng kể nào đối với hành vi được quan sát.

Có cách nào để chế ngự rm -rfđể chia sẻ đĩa nhiều hơn không? Tôi có cần sử dụng một kỹ thuật khác sẽ lấy tín hiệu từ nó ionicekhông?

Cập nhật:

Hệ thống tập tin được đề cập là một kho lưu trữ đối tượng AWS EC2 (đĩa chính là EBS). Các /etc/fstabentry trông như thế này:

/dev/xvdb       /mnt    auto    defaults,nobootwait,comment=cloudconfig 0       2

Có lẽ bạn cũng nên đề cập đến hệ thống tập tin mà bạn đang sử dụng và cách thức (tùy chọn gắn kết).
Cristian Ciupitu

Cập nhật. Ngoài ra, trong trường hợp có vấn đề, đây là trên Ubuntu 12.04.
David Eyk

Lưu ý rằng hiệu suất IO trên Amazon EBS có thể khá tệ. Xem perfcap.blogspot.com/2011/03/ Đề xuất tối đa 100 iops dài hạn, với thời gian ngắn (1 phút) bùng nổ lên đến 1000. Có vẻ như trường hợp của bạn cao hơn trong một phút, do đó có vấn đề.
Moshe Katz

Phải, đó là lý do tại sao chúng tôi sử dụng một cửa hàng cá thể, không phải EBS, cho bộ đệm. Xem bình luận cập nhật của tôi. Xin lỗi nếu điều đó không rõ ràng.
David Eyk

Xin lỗi tôi đến trễ, nhưng bạn có thể điều tra các nhóm và trình điều khiển blkio: kernel.org/doc/Documentation/cgroups/blkio-controll.txt
AndreasM

Câu trả lời:


3

Tất cả dữ liệu được thu thập từ trang này. Dưới đây là một số tùy chọn để xóa thư mục lớn của các tập tin. Kiểm tra writeup để biết chi tiết về cách thức này được sản xuất.

Lệnh đã hết thời gian hệ thống% CPU cs1 * (Vol / Invol)
rsync -aTHERdelete trống / a 10.60 1.31 95% 106/22
tìm b / -type f -delete 28,51 14,46 52% 14849/11
tìm c / -type f | xargs -L 100 rm 41,69 20,60 54% 37048/15074
tìm d / -type f | xargs -L 100 -P 100 rm 34,32 27,82 89% 929897/21720
rm -rf f 31,29 14,80 47% 15134/11

* cs1 là chuyển đổi ngữ cảnh tự nguyện và không tự nguyện


Trong khi về mặt lý thuyết có thể trả lời câu hỏi, tốt hơn là nên bao gồm các phần thiết yếu của câu trả lời ở đây và cung cấp liên kết để tham khảo.
Tom O'Connor

Hấp dẫn! Tôi sẽ thử nó.
David Eyk

rsyncđang chạy ngay bây giờ Có lẽ còn quá sớm để nói và có thể giúp tôi không chạy nó vào giữa buổi sáng bận rộn, nhưng máy chủ vẫn phản hồi nhanh và mức trung bình tải có thể quản lý được.
David Eyk

Lời mời chính xác mà tôi đang sử dụng:ionice -c 3 nice -19 rsync -a --delete /mnt/empty/ /mnt/nginx-cache-old
David Eyk

Chà, chỉ mất 4 giờ. ;) Tôi sẽ chấp nhận câu trả lời này (xin lỗi @aferber) vì tôi thích cách gọi đơn giản và dường như nó dễ bị ảnh hưởng niceionice, hoặc ít nhất là nó đã không phá hủy máy chủ như rm -rfđã làm.
David Eyk

9

Xóa tệp chỉ thực hiện các hoạt động siêu dữ liệu trên hệ thống tệp không bị ảnh hưởng bởi ionice.

Cách đơn giản nhất là, nếu bạn không cần không gian đĩa ngay bây giờ, để thực hiện rmtrong giờ thấp điểm.

Cách phức tạp hơn mà MIGHT làm việc là phân tán các xóa bỏ theo thời gian. Bạn có thể thử một cái gì đó như sau (lưu ý rằng nó giả sử đường dẫn và tên tệp của bạn KHÔNG chứa bất kỳ khoảng trắng nào!):

while find dir -type f | head -n 100 | xargs rm; do sleep 2; done
while find dir -type d -depth | head -n 100 | xargs rmdir; do sleep 2; done

Cũng lưu ý rằng bạn không thể sử dụng rm -ftrong lệnh đầu tiên vì sau đó vòng lặp sẽ không dừng (điều này phụ thuộc vào mã thoát lỗi rmkhi không có đối số).

Bạn có thể điều chỉnh nó bằng cách sửa đổi số lần xóa trong mỗi chu kỳ (100 trong ví dụ) và thời lượng ngủ. Tuy nhiên, nó có thể không thực sự hoạt động vì hệ thống tệp vẫn có thể kết hợp các bản cập nhật siêu dữ liệu theo cách bạn gặp rắc rối với tải IO của mình. Bạn chỉ cần cố gắng thôi.


Việc xóa nhiều tệp đó mất nhiều thời gian, vì vậy thực sự không có khoảng thời gian "ngoài giờ" nào sẽ bao gồm nó. :(
David Eyk

Các whilevòng lặp dường như làm các thủ thuật khi head -n 50. 100 vẫn đang dần tăng mức trung bình tải lên trên mức quan trọng, điều này cho tôi biết quá nhiều tranh chấp tài nguyên đang diễn ra.
David Eyk

Man, phải mất một thời gian dài để chạy!
David Eyk

Tìm kiếm vẫn sẽ liệt kê tất cả các tệp trong thư mục và tất cả các thư mục con cho mỗi lần lặp của vòng lặp while. Bạn có thể có thể làm tốt hơn với một cái gì đó như
Randy Orrison

1
Tìm kiếm vẫn sẽ liệt kê tất cả các tệp trong thư mục và tất cả các thư mục con cho mỗi lần lặp của vòng lặp while. Bạn có thể có thể làm tốt hơn với một cái gì đó như tìm dir -type f -print0 | xargs -l50 -0 rmwait trong đó rmwait là một tập lệnh thực hiện rm "$ @"; ngủ 2. Lưu ý việc sử dụng -print0 và -0 để xử lý tên tệp có dấu cách. -l50 bảo xargs chỉ làm 50 lần.
Randy Orrison

-1

Bạn có thể ghép nó với lệnh "đẹp". ionice -c 3 nice -19 rm -rf /some/folder

Điều này thay đổi mức độ ưu tiên của quy trình trên máy.


Thật không may, nicedường như có nhiều tác dụng như ionice, đó là, không có gì đáng giá.
David Eyk

@DavidEyk. Nếu tốt và ionice không có hiệu ứng "đáng chú ý", điều đó có nghĩa là không có gì khác đang tranh giành tài nguyên theo bất kỳ cách đáng tin cậy nào, hoặc đơn giản là bạn không nhận thấy hiệu ứng bằng mắt thường. Bạn thực sự nên đánh giá nó bằng cách sử dụng i bổ sung và vmstat để thấy hiệu quả thực sự.
Michael Martinez

Tôi tin rằng @aferber đã giải quyết vấn đề này trong câu trả lời của mình: "Việc xóa các tệp chỉ thực hiện các hoạt động siêu dữ liệu trên hệ thống tệp, không bị ảnh hưởng bởi ionice." Tôi đã thấy sự tranh chấp - các quy trình máy chủ của tôi đang đói trong thời gian đọc trong khi CPU bị mất và rm -rfcó 99% iotop.
David Eyk
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.