"No space left on device" chẳng bao giờ xuất hiện đúng lúc. Cơ sở dữ liệu ngừng nhận ghi, apt không hoàn tất được bản cập nhật, còn Docker từ chối kéo đúng cái image bạn đang cần. Tin tốt là: trên một VPS nhỏ, thủ phạm gần như luôn là một trong năm thứ, và bạn tìm ra nó trong hai phút.
1. Tình hình tệ đến đâu?
df -h /
df -i /
Dòng đầu cho thấy dung lượng đã dùng. Dòng thứ hai cho thấy inode — nếu inode chạm 100% trong khi dung lượng trông vẫn ổn, bạn đang có hàng triệu file tí hon (file phiên, hàng đợi thư, thư mục cache). Vấn đề khác, triệu chứng giống nhau.
2. Tìm thứ chiếm nhiều chỗ
Duyệt cây thư mục từ trên xuống và sắp xếp theo kích thước:
du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15
-x chỉ ở trên một hệ thống file, nên không lạc vào /proc. Sau đó đi sâu vào thứ lớn nhất. Để duyệt tương tác, ncdu dễ chịu hơn nhiều:
apt install -y ncdu
ncdu -x /
Phím mũi tên để di chuyển, d để xóa. Cẩn thận với phím cuối.
3. Những chiến thắng nhanh
Các lệnh này an toàn trên mọi máy chủ Ubuntu hay Debian:
apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M
apt autoremove cũng dọn các kernel cũ. Journal của systemd là thứ khiến nhiều người bất ngờ — nếu để mặc, nó có thể phình lên vài gigabyte. Để giới hạn vĩnh viễn, đặt SystemMaxUse=200M trong /etc/systemd/journald.conf rồi chạy systemctl restart systemd-journald.
4. Phần thừa của Docker
Nếu bạn chạy Docker, hãy xem chỗ này trước. Image cũ và cache build chồng chất sau mỗi lần deploy:
docker system df
docker image prune -a
docker builder prune
docker image prune -a xóa các image không được container đang chạy nào sử dụng. Thường đó là điều bạn muốn, nhưng lần deploy sau sẽ kéo chúng về lại.
Lệnh nguy hiểm là docker system prune -a --volumes. Volume chứa dữ liệu của bạn, và volume gắn với một container đã dừng được tính là không dùng. Người ta mất cơ sở dữ liệu theo đúng cách đó. Đừng dán lệnh này từ một câu trả lời trên diễn đàn.
Kẻ ngốn chỗ ẩn khác là log của container. Giới hạn chúng trong /etc/docker/daemon.json:
{
"log-driver": "json-file",
"log-opts": { "max-size": "10m", "max-file": "3" }
}
Sau đó khởi động lại Docker. Giới hạn chỉ áp dụng cho các container được tạo sau đó, nên hãy tạo lại những container ghi log nhiều bằng docker compose up -d --force-recreate.
5. Log và file bị bỏ quên
Tìm file lớn ở bất kỳ đâu trên ổ đĩa:
find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null
Những thứ thường gặp: một backup.tar.gz từ sáu tháng trước trong /root, một bản dump cơ sở dữ liệu ai đó định tải về, một log ứng dụng chưa bao giờ được xoay vòng.
Với log mà dịch vụ vẫn đang ghi vào, đừng dùng rm — hãy làm rỗng nó:
truncate -s 0 /var/log/myapp/app.log
Nếu bạn đã lỡ xóa một file và dung lượng không quay lại, thì có tiến trình vẫn đang giữ nó mở:
lsof +L1
Khởi động lại dịch vụ được liệt kê ở đó và dung lượng sẽ trở lại.
Khi dọn dẹp là chưa đủ
Đôi khi dữ liệu đơn giản là có thật — cơ sở dữ liệu ngày càng lớn, file người dùng tải lên, một file mô hình. Khi đó giải pháp thành thật là thêm ổ đĩa. Nâng cấp gói sẽ mở rộng ổ đĩa tại chỗ và giữ nguyên mọi thứ: Nano có 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Máy chủ khởi động lại một lần. Chi tiết có trong tài liệu về các gói.
Còn một thứ âm thầm ăn chỗ: file swap. Nếu bạn làm theo hướng dẫn swap của chúng tôi, 1–2 GB đó được dành ra có chủ đích. Và nếu Docker là thứ tiêu tốn nhiều nhất, hướng dẫn cài Docker và hướng dẫn stack Compose chỉ cách giữ số image trong tầm kiểm soát.
Thói quen ngăn được tất cả chuyện này: giới hạn journal và log Docker ngay từ ngày đầu. Hai dòng cấu hình, và chuyện "ổ đầy" gần như không còn xảy ra.
Bình luận
Chưa có bình luận nào. Hãy là người đầu tiên.