Một chương trình chạy sai đã tạo ra một số lượng lớn (ít nhất một triệu?) tệp vào /var/log. Ngay cả sau khi xóa tất cả các tệp giả mạo (?), mọi truy vấn trên thư mục/cây hiện mất khoảng 5 phút và có thể khiến toàn bộ hệ thống bị chậm.
Vấn đề là các tệp .gz được tạo bởi logrotate đã được thêm vào các kho lưu trữ .gz khác và chúng đang được lưu trữ và ... rất tiếc. Vì vậy, tất cả các tệp .gz không hợp lệ đã bị xóa khỏi /var/log - sự cố nguồn đã được khắc phục.
Làm thế nào tôi có thể tìm ra chính xác những gì vẫn gây ra sự chậm trễ?
- Trong cây /var/log có 75 thư mục với 1606 tệp, chỉ tiêu tốn 1GB.
ls /var/log mất hơn 5 phút để xử lý.- Các cây thư mục lớn hơn khác mất ít thời gian hơn để truy vấn với
ls, tìm thấy, tiếng kêu, vân vân.
cây trên /var/log cũng mất khoảng 5 phút và kết quả là một cây thư mục/tệp hoàn toàn bình thường.df -i hiển thị tổng cộng 10 triệu nút, ít hơn một triệu nút được sử dụng, hơn 9 triệu nút không sử dụng. Hệ thống đã được khởi động lại nhiều lần.
tôi sẽ ổn với rm -rf trên toàn bộ cây nhật ký, sau đó khởi động lại. Với mv hoặc cp sang một thư mục khác, "một số thiết lập lại" và di chuyển mọi thứ trở lại, tôi sẽ lo ngại rằng mình sẽ chỉ sao chép sự cố từ nơi này sang nơi khác.
Tôi tự hỏi liệu chúng tôi có thể quét/làm sạch các nút bị hỏng hay có thể giúp giảm số lượng nút xuống mức tối thiểu rồi khởi động lại sau khi khởi động lại.
Đó là một cài đặt đơn giản với /var trong phân vùng gốc / duy nhất cho hệ điều hành/dữ liệu. Vì vậy, ngắt kết nối/thay thế không phải là một tùy chọn.
Tôi có thể dễ dàng chạy chẩn đoán và cung cấp thông tin liên quan.
Đây là máy chủ đám mây v20.04.3 được vá đầy đủ. Tôi có thể mở bảng điều khiển nếu cần.
e4defrag không cho thấy sự phân mảnh. Có thể chạy fsck (e2fsck hoặc tắt máy -rF) nếu điều đó được khuyên.Đây là những ví dụ về các loại tiện ích mà tôi đang tìm kiếm để giúp chẩn đoán loại sự cố này.
