Đĩa đầy, du kể khác. Làm thế nào để điều tra thêm?

Tôi có một đĩa SCSI trong một máy chủ (phần cứng Raid 1), các tệp 32G, ext3. dfnói với tôi rằng đĩa đã đầy 100%. Nếu tôi xóa 1G, điều này được hiển thị chính xác.

Tuy nhiên, nếu tôi chạy du -h -x /thì sẽ ducho tôi biết rằng chỉ có 12G được sử dụng (tôi sử dụng -xvì một số gắn kết Samba).

Vì vậy, câu hỏi của tôi không phải là về sự khác biệt tinh tế giữa các lệnh du và df mà là làm thế nào tôi có thể tìm ra nguyên nhân gây ra sự khác biệt lớn này?

Tôi đã khởi động lại máy cho một fsck bị lỗi. Có nên chạy badblockskhông? lsofcho tôi thấy không có tệp bị xóa mở, lost+foundtrống và không có tuyên bố cảnh báo / err / fail rõ ràng trong tệp tin.

Hãy hỏi để biết thêm chi tiết về việc thiết lập.

Kiểm tra các tập tin trên nằm dưới điểm gắn kết. Thường xuyên nếu bạn gắn một thư mục (giả sử là một sambaf) vào một hệ thống tệp đã có tệp hoặc thư mục trong đó, bạn sẽ mất khả năng xem các tệp đó, nhưng chúng vẫn tiêu tốn dung lượng trên đĩa bên dưới. Tôi đã có các bản sao tệp trong khi ở chế độ người dùng kết xuất các tệp vào các thư mục mà tôi không thể nhìn thấy ngoại trừ trong mã đơn (do các hệ thống thư mục khác được gắn trên đầu chúng).

Chỉ vấp ngã trên trang này khi cố gắng theo dõi một vấn đề trên máy chủ cục bộ.

Trong trường hợp của tôi, df -hvà du -shkhông khớp với khoảng 50% kích thước đĩa cứng.

Điều này được gây ra bởi apache (httpd) giữ các tệp nhật ký lớn trong bộ nhớ đã bị xóa khỏi đĩa.

Điều này đã được theo dõi bằng cách chạy lsof | grep "/var" | grep deletednơi /varphân vùng tôi cần để dọn dẹp.

Đầu ra cho thấy các dòng như thế này:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

Tình huống sau đó đã được giải quyết bằng cách khởi động lại apache ( service httpd restart) và xóa 2gb dung lượng ổ đĩa, bằng cách cho phép các khóa trên các tệp bị xóa bị xóa.

Tôi đồng ý với câu trả lời của OldTroll là nguyên nhân có thể xảy ra nhất cho không gian "mất tích" của bạn.

Trên Linux, bạn có thể dễ dàng chuyển toàn bộ phân vùng gốc (hoặc bất kỳ phân vùng nào khác cho vấn đề đó) sang một nơi khác trong hệ thống tập tin của bạn, ví dụ, chỉ cần phát hành một

mount -o bind / /mnt

sau đó bạn có thể làm một

du -h /mnt

và xem những gì sử dụng không gian của bạn.

Ps: xin lỗi vì đã thêm câu trả lời mới và không bình luận nhưng tôi cần một số định dạng để bài đăng này có thể đọc được.

Xem những gì df -inói. Có thể là bạn đã hết inodes, điều này có thể xảy ra nếu có một số lượng lớn các tệp nhỏ trong hệ thống tệp đó, sử dụng hết tất cả các nút có sẵn mà không tiêu tốn hết dung lượng có sẵn.

Trong trường hợp của tôi, điều này phải làm với các tệp bị xóa lớn. Thật khó để giải quyết trước khi tôi tìm thấy trang này, điều này đặt tôi vào con đường chính xác.

Cuối cùng tôi đã giải quyết vấn đề bằng cách sử dụng lsof | grep deleted, trong đó cho tôi thấy chương trình nào đang giữ hai tệp nhật ký rất lớn (tổng cộng 5GB phân vùng gốc 8GB có sẵn của tôi).

Các tệp được mở bởi một chương trình không thực sự biến mất (ngừng tiêu thụ dung lượng đĩa) khi bạn xóa chúng, chúng sẽ biến mất khi chương trình đóng chúng. Một chương trình có thể có một tệp tạm thời rất lớn mà bạn (và du) không thể xem. Nếu đó là chương trình zombie, bạn có thể cần phải khởi động lại để xóa các tệp đó.

Hãy thử điều này để xem nếu một quá trình chết / treo bị khóa trong khi vẫn ghi vào đĩa: lsof | grep "/ mnt"

Sau đó thử tiêu diệt bất kỳ bộ vi xử lý nào bị mắc kẹt (đặc biệt là tìm các dòng kết thúc bằng "(đã xóa"))

Đây là phương pháp đơn giản nhất mà tôi đã tìm thấy cho đến nay để tìm các tệp lớn!

Dưới đây là một ví dụ nếu mount gốc của bạn đã đầy / (mount / root) Ví dụ:

cd / (vì vậy bạn đang ở trong root)

ls | xargs du -hs

Kết quả ví dụ:

 Thùng 9,4M
 Khởi động 63M
 Nhóm 4.0K
 Nhà phát triển 680K
 31 triệu
 Nhà 6,3G
 NÓ
 LibM 32M
 Mất 16K + tìm thấy
 Phương tiện truyền thông 61G
 4.0 triệu
 Lựa chọn 113M
 du: không thể truy cập `Proc / 6102 / task / 6102 / fd / 4 ': Không có tệp hoặc thư mục như vậy
 0 Proc
 Rễ 19M
 Chạy 840K
 Thùng 19M
 Selinux 4.0K
 4.0K
 Cửa hàng 25G
 Tmp 26 triệu

sau đó bạn sẽ nhận thấy rằng cửa hàng lớn làm một cd / cửa hàng

và chạy lại

ls | xargs du -hs

Ví dụ đầu ra: 
 Sao lưu 109M
 358M
 Iso 4.0G
 8,0 ks
 Mất 16K + tìm thấy
 Rễ 47M
 Kịch bản 11 triệu
 Tmp 79M
 21G vms

trong trường hợp này thư mục vms là không gian hog.

Đối với tôi, tôi cần phải chạy sudo duvì có một số lượng lớn tệp tin docker /var/lib/dockermà người dùng không phải sudo không có quyền đọc.

Thêm một khả năng để xem xét - bạn gần như được đảm bảo sẽ thấy sự khác biệt lớn nếu bạn đang sử dụng docker và bạn chạy df / du bên trong một container đang sử dụng ngàm âm lượng. Trong trường hợp thư mục được gắn vào ổ đĩa trên máy chủ docker, df sẽ báo cáo tổng số df của HOST. Điều này là hiển nhiên nếu bạn nghĩ về nó, nhưng khi bạn nhận được báo cáo về "thùng chứa chạy trốn lấp đầy đĩa!", Hãy đảm bảo bạn xác minh mức tiêu thụ không gian tệp của bộ chứa với thứ gì đó như du -hs <dir>.

Vì vậy, tôi cũng gặp vấn đề này ở Centos 7 và tìm ra giải pháp sau khi thử một loạt các thứ như Bleachbit và dọn dẹp / usr và / var mặc dù chúng chỉ hiển thị khoảng 7G mỗi cái. Vẫn hiển thị 50G 50G được sử dụng trong phân vùng gốc nhưng chỉ hiển thị 9G sử dụng tệp. Chạy một đĩa CD ubfox trực tiếp và ngắt kết nối phân vùng 50G vi phạm, mở thiết bị đầu cuối và chạy xfs_check và xfs_V ngoặc trên phân vùng. Sau đó tôi đã ghi lại phân vùng và thư mục bị mất + tìm thấy của tôi đã mở rộng lên 40G. Sắp xếp mất + tìm thấy theo kích thước và tìm thấy tệp nhật ký văn bản 38G cho hơi nước mà cuối cùng chỉ lặp lại một lỗi mp3. Đã xóa tệp lớn và bây giờ có dung lượng và việc sử dụng đĩa của tôi đồng ý với kích thước phân vùng gốc của tôi. Tôi vẫn muốn biết làm thế nào để có được nhật ký hơi nước để không phát triển quá lớn nữa.

nếu đĩa được gắn là một thư mục dùng chung trên máy windows, thì có vẻ như df sẽ hiển thị kích thước và mức độ sử dụng đĩa của toàn bộ đĩa windows, nhưng du sẽ chỉ hiển thị phần của đĩa mà bạn có quyền truy cập. (và được gắn kết). Vì vậy, trong trường hợp này, vấn đề phải được khắc phục trên máy tính windows.

Một điều tương tự đã xảy ra với chúng tôi trong sản xuất, việc sử dụng đĩa đã đạt tới 98%. Đã điều tra như sau:

a) df -iđể kiểm tra mức sử dụng inode, mức sử dụng inode là 6% nên không phải các tệp nhỏ hơn nhiều

b) Gắn rootvà kiểm tra các tập tin ẩn. Không thể gửi bất kỳ tập tin bổ sung . dukết quả giống như trước khi gắn kết.

c) Cuối cùng, kiểm tra nginxnhật ký. Nó được cấu hình để ghi vào đĩa nhưng một nhà phát triển đã xóa tệp nhật ký trực tiếp gây ra nginxđể giữ tất cả các bản ghi trong bộ nhớ. Vì tệp /var/log/nginx/access.logđã bị xóa khỏi đĩa bằng cách sử rmdụng, dunhưng tệp này không được truy cập nginxvà do đó nó vẫn được giữ mở

Tôi đã có cùng một vấn đề được đề cập trong chủ đề này, nhưng trong một VPS. Vì vậy, tôi đã thử nghiệm mọi thứ được mô tả trong chủ đề này nhưng không thành công. Giải pháp là một liên hệ hỗ trợ với nhà cung cấp VPS của chúng tôi tham gia biểu diễn một tính toán lại hạn ngạch và điều chỉnh sự khác biệt không gian của df -hvà du-sh /.

Tôi gặp vấn đề này trên một hộp FreeBSD ngày hôm nay. Vấn đề là nó là một tạo tác của vi(không vim, không chắc chắn nếu vimtạo ra vấn đề này). Các tập tin đã tiêu tốn dung lượng nhưng chưa được ghi vào đĩa.

Bạn có thể kiểm tra xem với:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

Cái này nhìn vào tất cả các tệp đang mở và sắp xếp (thông qua số -n) theo cột thứ 8 (khóa, -k8), hiển thị mười mục cuối cùng.

Trong trường hợp của tôi, mục cuối cùng (lớn nhất) trông như thế này:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

Điều này có nghĩa là quá trình (PID) 12345 đã tiêu thụ 1,46G (cột thứ tám chia cho 1024³) đĩa mặc dù thiếu thông báo du. vithật kinh khủng khi xem các tập tin cực lớn; thậm chí 100MB là lớn đối với nó. 1.5G (hoặc lớn mà tập tin thực sự là) là vô lý.

Giải pháp là sudo kill -HUP 12345(nếu điều đó không hiệu quả, tôi sudo kill 12345và nếu điều đó cũng thất bại, sự sợ hãi kill -9sẽ xuất hiện).

Tránh các trình soạn thảo văn bản trên các tệp lớn. Cách giải quyết mẫu để lướt nhanh:

Giả sử độ dài dòng hợp lý:

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

Giả sử (các) dòng lớn bất hợp lý:

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

Chúng được sử dụng vim -Rthay viewvì vimgần như luôn luôn tốt hơn ... khi nó được cài đặt. Hãy thoải mái để ống chúng vào viewhoặc vi -Rthay vào đó.

Nếu bạn đang mở một tệp lớn như vậy để thực sự chỉnh sửa nó, hãy xem xét sedhoặc awkhoặc một số phương pháp lập trình khác.

kiểm tra xem máy chủ của bạn đã cài đặt tác nhân ossec chưa. Hoặc một số công cụ đang sử dụng các tệp nhật ký đã xóa. Trong một thời gian trước đây của tôi là đại lý ossec.

kiểm tra / mất + tìm thấy, tôi có một hệ thống (centos 7) và một số tệp trong / mất + được tìm thấy đã ăn hết dung lượng.