Điểm:0

Can't get disk space back after running out of space (and removing some files) in Ubuntu 18.04

lá cờ in

This is driving me crazy! My server run out of space. I cleaned up some files by removing the folders. The amount of free space didn't go up (% wise). This is what I now see:

enter image description here

As you can see, it shows 315gb size, of which 298gb is in use. So why does it show 100% used? The only reason I have the 1.1gb free that you can see if due to removing more files are reboot. Even though I got rid of 15+gb of files before :/

I've tried quite a few things such as lsof +L1:

    COMMAND    PID      USER   FD   TYPE DEVICE SIZE/OFF NLINK  NODE NAME
php-fpm7.  726      root    3u   REG    8,0        0     0   605 /tmp/.ZendSem.sRUIJj (deleted)
mysqld     863     mysql    5u   REG    8,0        0     0  2938 /tmp/ibj2MjTy (deleted)
mysqld     863     mysql    6u   REG    8,0        0     0 10445 /tmp/ibgsRaLu (deleted)
mysqld     863     mysql    7u   REG    8,0        0     0 76744 /tmp/ibx2g3Cq (deleted)
mysqld     863     mysql    8u   REG    8,0        0     0 76750 /tmp/ib7D93oi (deleted)
mysqld     863     mysql   12u   REG    8,0        0     0 77541 /tmp/ibSr0xre (deleted)
dovecot   1278      root  139u   REG   0,23        0     0  2021 /run/dovecot/login-master-notify6ae65d15ebbecfbf (deleted)
dovecot   1278      root  172u   REG   0,23        0     0  2022 /run/dovecot/login-master-notify4b18cb63ddb75aab (deleted)
dovecot   1278      root  177u   REG   0,23        0     0  2023 /run/dovecot/login-master-notify05ff81e3cea47ffa (deleted)
cron      2239      root    5u   REG    8,0        0     0  1697 /tmp/#1697 (deleted)
cron      2240      root    5u   REG    8,0        0     0 77563 /tmp/#77563 (deleted)
sh        2243      root   10u   REG    8,0        0     0  1697 /tmp/#1697 (deleted)
sh        2243      root   11u   REG    8,0        0     0  1697 /tmp/#1697 (deleted)
sh        2244      root   10u   REG    8,0        0     0 77563 /tmp/#77563 (deleted)
sh        2244      root   11u   REG    8,0        0     0 77563 /tmp/#77563 (deleted)
imap-logi 2512  dovenull    4u   REG   0,23        0     0  2023 /run/dovecot/login-master-notify05ff81e3cea47ffa (deleted)
imap-logi 3873  dovenull    4u   REG   0,23        0     0  2023 /run/dovecot/login-master-notify05ff81e3cea47ffa (deleted)
pop3-logi 3915  dovenull    4u   REG   0,23        0     0  2021 /run/dovecot/login-master-notify6ae65d15ebbecfbf (deleted)
pop3-logi 3917  dovenull    4u   REG   0,23        0     0  2021 /run/dovecot/login-master-notify6ae65d15ebbecfbf (deleted)
php-fpm7. 4218    fndesk    3u   REG    8,0        0     0   605 /tmp/.ZendSem.sRUIJj (deleted)
php-fpm7. 4268 executive    3u   REG    8,0        0     0   605 /tmp/.ZendSem.sRUIJj (deleted)

But I can't see anything in there that is locking the files up

Michael Hampton avatar
lá cờ cz
Khởi động lại các chương trình đang mở các tệp đó hoặc khởi động lại máy tính.
Andrew Newby avatar
lá cờ in
@MichaelHampton cảm ơn, nhưng tôi đã thử khởi động lại toàn bộ máy chủ nhiều lần :( Có vẻ như nó không muốn từ bỏ nó!
Michael Hampton avatar
lá cờ cz
Sau đó, bạn cần xóa nhiều tệp hơn.
lá cờ in
Điều này có trả lời câu hỏi của bạn không? [Đĩa đầy, du nói khác. Làm cách nào để điều tra thêm?](https://serverfault.com/questions/275206/disk-full-du-tells-different-how-to-further-investigate)
Andrew Newby avatar
lá cờ in
@MichaelHampton Tôi không cần phải làm vậy. Máy chủ đang chạy tốt và có vô số dung lượng trống trước khi hết. Tôi đã tải lên một tệp lớn, và sau đó nó bị sập với tôi (ừm, nó cứ báo cho tôi biết "hết dung lượng đĩa", đúng như vậy). Nhưng ngay cả sau khi xóa tệp đó, nó vẫn không thay đổi% dung lượng trống.Tùy chọn duy nhất khác là tôi cập nhật máy chủ lên phiên bản mới hơn và di chuyển tất cả các tệp qua - và tôi có thể đảm bảo rằng điều đó sẽ khắc phục được sự cố (nhưng đó là những ngày làm việc, đối với một số thứ thậm chí không phải là vấn đề :()
Michael Hampton avatar
lá cờ cz
Một cái gì đó đang lấp đầy đĩa của bạn. Bạn có thể tiếp tục điều tra nó, hoặc không, đó là lựa chọn của bạn.
Andrew Newby avatar
lá cờ in
@MichaelHampton Tôi đang cố gắng;) Nhưng nó vẫn vô nghĩa. `/dev/sda 315G 296G 2.9G 100% /` - 315gb - 296gb = 19gb... nhưng dung lượng "có sẵn" chỉ hiển thị là 2,9gb .. vì vậy thứ gì đó đang nuốt hết dung lượng đó
Michael Hampton avatar
lá cờ cz
Bạn có nghĩa là đặt phòng gốc 5%?
Andrew Newby avatar
lá cờ in
@MichaelHampton hmmm ok, điều đó hợp lý hơn - 16gb + 2,9gg. Tôi đã không nhận ra nó đã được đặt trước?
Michael Hampton avatar
lá cờ cz
Hầu hết các hệ thống tệp Unix đã thực hiện từ thời xa xưa, mặc dù nó đã không còn được ưa chuộng và các hệ thống tệp hiện đại hơn không còn làm điều đó nữa.
Andrew Newby avatar
lá cờ in
@MichaelHampton ah ok có lẽ đó là lý do tại sao tôi không nhận thấy nó trước đây. Hầu hết các máy chủ khác là UB 20.04, nhưng tôi thực sự gặp bất kỳ vấn đề nào với dung lượng ổ đĩa trên những máy chủ đó vì chúng có ít trang web hơn
Điểm:2
lá cờ in

Tìm hiểu điều gì đang ngốn dung lượng ổ đĩa, sau đó tìm hiểu lý do tại sao, trước khi xóa thứ gì đó.

Để hiển thị "10 thư mục hàng đầu", bạn có thể sử dụng du -Sh / | sắp xếp -rh | đầu -10.

Để hiển thị các tệp "Top 10"", bạn có thể sử dụng tìm / -type f -exec du -Sh {} + | sắp xếp -rh | đầu -n 10.

Thường thì bạn sẽ tìm thấy các tệp nhật ký khổng lồ hoặc không được xoay vòng, của các tệp nhật ký được điền nhanh. Tùy thuộc vào phát hiện của bạn, đôi khi chỉ cần xóa một số tệp nhật ký cũ hơn hoặc định cấu hình xoay vòng nhật ký hoặc định cấu hình cài đặt nhật ký cho các dịch vụ của bạn là đủ.

Về tính toán của bạn: Điều này không nhất thiết phải khiến bạn phát điên :-)

Thông thường các hệ thống tập tin dành 5% dung lượng cho người dùng root. Bạn có kích thước đĩa 315G, vì vậy 5% sẽ là ~16G dung lượng dành riêng. Có một bài viết hay giải thích nền tảng: https://blog.tinned-software.net/utility-df-shows-inconsistent-calculation-for-ext-filesystems/

Andrew Newby avatar
lá cờ in
Cảm ơn vì điều đó. Trên thực tế, có vẻ như phần lớn các bảng mySQL được lựa chọn (6+gb một số trong số chúng , nhưng chúng có hàng triệu hàng). Tôi sẽ xem liệu tôi có thể tìm cách tối ưu hóa bất kỳ cách nào trong số chúng không, vì đó sẽ là một chiến thắng nhanh chóng
Andrew Newby avatar
lá cờ in
Tôi cũng tìm thấy ở một nơi khác rằng ký ức đang diễn ra. Chúng tôi sử dụng các bảng mySQL của InnoDB và nơi chúng tôi đã thực hiện "xóa" lớn, các tệp IBD không bị giảm kích thước. Rõ ràng đây là hành vi bình thường đối với InnoDB.Cách xung quanh nó là sao chép bảng và sau đó đổi tên nó. Điều này đã lấy một tệp 16gb, giảm xuống chỉ còn hơn 10gb :)

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.