Hết dung lượng đĩa, nguồn là gì?

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  220G     0 100% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  220G     0 100% /var/lib/ureadahead/debugfs

Trong khi hoảng loạn tìm kiếm câu trả lời sau những gì có vẻ như tuổi tác, việc sử dụng giảm

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  9.3G  200G   5% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  9.3G  200G   5% /var/lib/ureadahead/debugfs

Tôi đã không xóa bất cứ điều gì cho đến nay và bây giờ tôi đang viết nó trở lại

/dev/sda1             220G   12G  197G   6% /

Chuyện gì vậy ?? Làm cách nào tôi có thể điều tra nguyên nhân và thiết lập mọi thứ để nó không xảy ra lần nữa Tôi ngăn điều này xảy ra lần nữa

Trong suốt thời gian sử dụng massage, tôi thấy rằng kích thước của thư mục / var không đổi ở mức 1,8 hợp đồng nhưng tôi không thể kiểm tra tất cả các thư mục

chỉnh sửa đi lên

/dev/sda1             220G   18G  192G   9% /

* cập nhật 2 * Nó sẽ tăng trở lại

ubuntu /: df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G   43G  167G  21% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G   43G  167G  21% /var/lib/ureadahead/debugfs

Và kiểm tra lệnh tôi đã được đưa ra

ubuntu /: du -h --max-depth=1 /
31M     /boot
4.0K    /selinux
8.0K    /srv
7.4M    /bin
du: cannot access `/proc/9993/task/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/task/9993/fdinfo/4': No such file or directory
du: cannot access `/proc/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/fdinfo/4': No such file or directory
0       /proc
12K     /tmp
2.4G    /var
0       /sys
100K    /root
4.0K    /media
575M    /usr
4.0K    /opt
16K     /lost+found
4.5M    /home
270M    /lib
168K    /dev
4.0K    /mnt
6.7M    /sbin
6.1M    /etc
4.0K    /cdrom
3.3G    /

lưu ý 3,3G cho /

Tôi nghĩ rằng bạn có một cái gì đó ghi vào một tệp đã bị xóa khỏi ổ đĩa nhưng chưa được đóng bởi ứng dụng / máy chủ, vì vậy không gian vẫn được phân bổ trên đĩa nhưng không thể nhìn thấy duvì tệp đã bị xóa khỏi hệ thống tệp. Các lsofquá trình danh sách chương trình có file mở. Nếu bạn có nhiều hệ thống tập tin được gắn kết và số lượng không dao động quá nhiều, thì tôi đã gợi ý rằng bạn có một hệ thống tập tin được gắn trên đầu thư mục không trống (mặc dù bạn có thể thử umount /var/lib/ureadahead/debugfsvà đảm bảo rằng thư mục đó trống và không có một đống rác được ghi vào thư mục ẩn dưới đỉnh núi đó).

Nếu đây là trường hợp, sau đó bạn nên dễ dàng tìm thấy những với sudo lsof | grep deleted. lsofbao gồm (deleted)trong cột cuối cùng nếu một tệp đã bị xóa trong khi một quá trình vẫn mở nó. Cột đầu tiên là tên của lệnh, cột thứ hai là PID. psVí dụ ps auxww | grep PID, ps auxwwf | less -Sbạn có thể xem chi tiết hơn về lệnh bằng cách sử dụng hoặc để xem danh sách quy trình trong chế độ "rừng" để bạn có thể xem quy trình mà PID đó đến từ đâu. Khi bạn đã theo dõi quá trình đang giữ các tệp khổng lồ đang mở, bạn có thể dừng nó để giải phóng dung lượng ổ đĩa, sau đó tìm ra cách khắc phục để đóng tệp đúng cách. Nguyên nhân thông thường của việc này là do tập lệnh logrotate đổi tên / xóa các tệp nhật ký nhưng không thông báo cho ứng dụng rằng nó đã thực hiện (thông qua một tín hiệu thích hợp vớikill hoặc bằng cách khởi động lại ứng dụng), vì vậy ứng dụng tiếp tục giữ tệp nhật ký cũ mở.

Chạy

du -h --max-depth=1 /

Và nó sẽ cho một hình ảnh rõ ràng hơn. Nếu nó đến và đi, có vẻ như các tệp tạm thời được tạo và sau đó không bị xóa sau khi thực hiện, cho đến khi bất kỳ quá trình nào gây ra sự cố. Hệ điều hành nào là máy chủ này chạy và nó có chạy gì đặc biệt không?

Có vẻ như vấn đề là /var/lib/ureadahead/debugfs. Có vẻ như đây là một vấn đề đã biết, đây là một liên kết đến ubuntuforums với nhiều thông tin hơn http://ubuntuguide.net/howto-fix-ureadahead-probols-after-upgrad-to-ub Ubuntu-10-04 . Các tl; dr dường như được cập nhật và nâng cấp sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled, sau đó khởi động lại. Tất nhiên, tôi giả sử bạn đang chạy 10.04.

Tôi đoán là các tập tin nhật ký; Tôi đã có rất nhiều cảnh báo "không dùng được" của PHP 5.3 trong nhật ký Apache của tôi trên máy chủ dev mà tôi không thực sự chú ý đến việc nó đã nhai hết 8GB dung lượng trên phân vùng var của tôi (như là một vấn đề phụ: bạn nên luôn luôn đặt / var trên một phân vùng riêng mà phân vùng gốc của bạn hết dung lượng có thể gây ra sự cố mất ổn định hệ thống).

Nếu không gian được tiêu thụ rất nhanh (không phải theo độ tuổi), thì có lẽ đó chỉ là phân bổ tệp.

Nguyên nhân có thể là trao đổi lớn hoặc các tệp tạm thời cho một số ứng dụng, được làm trống sau quá trình của nó.

Làm một du --max-length=1khi không gian được tiêu thụ rất nhiều.

Nếu bạn nghĩ rằng thư mục gốc của bạn mất quá nhiều (3,3 GB), hãy thử ll -a / và đăng kết quả.

Có vẻ như /var/lib/ureadahead/debugfscó thể là một cá trích đỏ. Đây là lý do tại sao...

Trong khi /var/lib/ureadahead/debugfskhông tồn tại /etc/mtab, nó không được tìm thấy trong /proc/mounts:

$ mount | grep debug
none on /sys/kernel/debug type debugfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

$ cat /proc/mounts | grep debug
none /sys/kernel/debug debugfs rw,relatime 0 0

Các dflệnh dường như được báo cáo chính xác những điều tương tự cho /var/lib/ureadahead/debugfsvà/

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   1681128   8115792  18% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   1681128   8115792  18% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Tạo tệp 1GB trong /tmp:

$ dd if=/dev/zero of=/tmp/carypjunk.out bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 52.7234 s, 20.4 MB/s

Hiển thị kích thước được báo cáo ở cả hai nơi:

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   2730216   7066704  28% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   2730216   7066704  28% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Vì vậy, có vẻ như /var/lib/ureadahead/debugfsthiết bị là một cá trích đỏ vì nó chỉ phản ánh các số liệu thống kê từ /. Nếu bạn sắp hết dung lượng, đó là do thứ gì đó lấp đầy hệ thống tập tin gốc của bạn. Tôi sẽ kiểm tra / var / log của bạn trước.

Vấn đề đã được bắt đầu bởi một tác vụ cron thực thi lệnh php CLI mỗi phút. Mã PHP dường như bị mắc kẹt trong một số loại vòng lặp điên rồ của các lỗi bị bắt và lượng dữ liệu gỡ lỗi khổng lồ đang tăng lên với tốc độ của bộ xử lý.

Vì mã php được thực thi mất hơn một phút nên nó không xem xét công việc được thực hiện, nó tiếp tục thực thi lặp đi lặp lại làm tăng tốc độ tăng trưởng của dữ liệu (tạm thời?).

Nhiệm vụ tương tự đã được thực hiện trong gần một tháng mà không có vấn đề gì, vì vậy nó không phải là nguyên nhân của tôi.

Điều kỳ lạ là tập lệnh php đặt thời gian thực hiện tối đa theo cách thủ công

Tôi đã kiểm tra php.ini để tìm manh mối

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30

; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpect$
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60

Nó nói rằng các giá trị được mã hóa cứng không giới hạn cho CLI! Ôi