lệnh du mất quá nhiều thời gian để chạy

Tôi đang chạy du -shtrong một loạt các thư mục để tìm ổ đĩa. Tôi đã có hai máy chủ giống hệt nhau (Dell PE2850), cả hai đều có RHEL5 và sẽ mất nhiều thời gian hơn để chạy dutrên một máy chủ khác.

Ví dụ: thực hiện du -sh /opt/foobarsẽ mất 5 phút trên máy chủ A (có khoảng 25 GB trong đó) và trên máy chủ B, cùng một lệnh với cùng một lượng dữ liệu sẽ báo cáo lại cho tôi gần như ngay lập tức. Tôi không thấy bất cứ điều gì rõ ràng rõ ràng khi chạy hàng đầu, vv

Bất cứ lời khuyên nào cũng đươc đánh giá cao.

— Jon Weinraub
nguồn

Tốc độ du -skhông phụ thuộc vào kích thước của dữ liệu mà phụ thuộc vào số lượng tệp. Cả hai cây thư mục có số lượng tập tin tương tự nhau?

— Ladadadada

Ngoài ra, dusẽ hoạt động nhanh hơn nhiều nếu tất cả dữ liệu meta thư mục (như kích thước tệp) hiện được lưu trữ. Nếu đây là trường hợp vì bất kỳ lý do gì trên một máy chủ chứ không phải máy chủ khác, nó sẽ dẫn đến sự khác biệt lớn.

— Sven

@Ladadada Tôi sẽ nói có, có cùng số lượng tệp. Ngay cả khi thêm dấu hoa thị để có được danh sách các kích thước tệp riêng lẻ cũng mất nhiều thời gian để cuộn. Nhưng tôi không hoàn toàn chắc chắn làm thế nào để xác minh xem dữ liệu meta có được lưu trữ hay không.

— Jon Weinraub

Câu trả lời:

Nếu bạn có số lượng tệp khổng lồ trong thư mục đó và nội dung của thư mục liên tục thay đổi, mục nhập thư mục sẽ bị phân mảnh theo thời gian. Sau đó, khi HĐH đang đọc nội dung thư mục, sẽ có rất nhiều tìm kiếm đĩa không cần thiết. Điều này đặc biệt xảy ra với các hệ thống tập tin ext * (ext4 có thể tốt hơn) và các hệ thống tập tin ReiserFS v3.x cũ (nếu đã vượt quá 85% hoặc hơn).

Giải pháp khá dễ dàng:

cp -pr origdir newdir
mv origdir origdir.bak
mv newdir origdir

Tất nhiên, nếu mọi thứ được lưu trong bộ nhớ cache, điều này không quan trọng lắm; Linux thường lưu trữ các tập tin và thư mục thường xuyên truy cập khá tích cực. Nếu bạn thực sự muốn giữ nội dung của các thư mục đó trong RAM, bạn có thể đặt một cái gì đó giống như ls -lah /your/dir 2>&1 >/dev/nullcron của bạn.

EDIT: Ồ, một điều xuất hiện trong tâm trí của tôi. Nếu máy chủ của bạn có bộ điều khiển RAID được sao lưu bằng pin với một số bộ đệm trong đó, vui lòng kiểm tra xem pin có ổn không. Tôi đã thấy tình huống pin hết và bộ điều khiển vô hiệu hóa hoàn toàn bộ đệm, làm hỏng hiệu năng rất tệ. Ví dụ, các máy chủ HP có thể cho biết trong iLO ghi nhật ký gì đó về pin của bộ điều khiển; trong bảng điều khiển sức khỏe máy chủ thực tế, mọi thứ dường như đều tốt và xanh, nhưng chỉ có mục nhật ký sẽ cho bạn biết về điều này.

— Janne Pikkarainen
nguồn

Điều này có thể sẽ khiến tôi mất một chút thời gian để thực hiện, nó nằm trên một máy chủ sản xuất nên tôi sẽ cần thực hiện qua đêm và toàn bộ thư mục chứa hàng trăm gigabyte dữ liệu nên tôi không muốn làm hỏng nó ... Tôi sẽ báo cáo Điều đầu tiên vào sáng mai. Cảm ơn ý kiến.

— Jon Weinraub

Tôi vẫn đang chạy lệnh này và không biết sẽ mất bao lâu. Tôi thậm chí đã đổi tên nó và cp vẫn đang chạy, khoảng 1 giờ 15 phút kể từ khi bắt đầu. Ngay cả việc chạy một du trên thư mục đó trong một shell khác cũng mất nhiều thời gian, nhưng bạn nghĩ tôi chỉ nên dùng umountổ đĩa fsckchứ?

— Jon Weinraub

Chỉ cần để nó chạy trừ khi nó làm phiền sản phẩm của bạn bằng cách nào đó. Với RHEL5 và bộ lập lịch I / O CFQ mặc định của nó, bạn có thể đặt lệnh cp trong lớp nhàn rỗi để nó không bắt nạt các quy trình khác: ionice -c3 -p $(pidof cp)hoặc như vậy.

— Janne Pikkarainen

Xin vui lòng đọc bản chỉnh sửa mới nhất của tôi.

— Janne Pikkarainen

Tôi biết đã được một thời gian nhưng cuối cùng tôi cũng đã thực hiện được lệnh cp mà bạn đề cập. Nó hai hai giờ để sao chép 25 GB. Sau khi thực hiện di chuyển hte, chạy một du -sh khác cũng chậm như vậy. Trong thực tế, ngay cả việc xóa các thư mục sao lưu cũng chậm!

— Jon Weinraub

Tôi đề nghị thử lệnh du đơn giản mà không cần bất kỳ công tắc. Cuối cùng bạn sẽ thấy thư mục nào đang làm chậm quá trình. Có thể là một đĩa bị lỗi, hoặc một số lý do khác, ...

— Király István
nguồn