پیام "No space left on device" هیچوقت سر وقت مناسب نمیآید. پایگاه داده دیگر نوشتن را قبول نمیکند، apt نمیتواند بهروزرسانی را تمام کند و Docker حاضر نیست همان ایمیجی را که همین حالا لازم دارید دانلود کند. خبر خوب: روی یک VPS کوچک مقصر تقریباً همیشه یکی از پنج چیز است و در دو دقیقه پیدایش میکنید.
۱. اوضاع چقدر بد است؟
df -h /
df -i /
خط اول فضای مصرفشده را نشان میدهد. خط دوم inodeها را — اگر inodeها به ۱۰۰ درصد برسند در حالی که فضا خوب به نظر میرسد، میلیونها فایل ریز دارید (فایلهای نشست، صف ایمیل، پوشهی کش). مشکل متفاوت، همان علامت.
۲. پیدا کنید چه چیزی بزرگ است
درخت را از بالا مرور کنید و بر اساس اندازه مرتب کنید:
du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15
گزینهی -x روی یک فایلسیستم میماند تا وارد /proc نشود. بعد سراغ بزرگترین مورد بروید. برای گشتن تعاملی، ncdu خیلی راحتتر است:
apt install -y ncdu
ncdu -x /
کلیدهای جهت برای جابهجایی، d برای حذف. با آخری مراقب باشید.
۳. بردهای سریع
اینها روی هر سرور Ubuntu یا Debian امناند:
apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M
apt autoremove کرنلهای قدیمی را هم پاک میکند. ژورنال systemd همان چیزی است که همه را غافلگیر میکند — اگر رهایش کنید میتواند تا چند گیگابایت بزرگ شود. برای محدود کردن دائمیاش، SystemMaxUse=200M را در /etc/systemd/journald.conf تنظیم کنید و systemctl restart systemd-journald را اجرا کنید.
۴. باقیماندههای Docker
اگر Docker دارید، اول اینجا را ببینید. ایمیجهای قدیمی و کش بیلد با هر دیپلوی روی هم جمع میشوند:
docker system df
docker image prune -a
docker builder prune
docker image prune -a ایمیجهایی را که هیچ کانتینر در حال اجرایی استفاده نمیکند حذف میکند. معمولاً همین را میخواهید، اما دیپلوی بعدی دوباره دانلودشان میکند.
خطرناکش docker system prune -a --volumes است. ولومها دادههای شما را نگه میدارند، و ولومی که به یک کانتینر متوقف وصل است بلااستفاده حساب میشود. آدمها اینطوری پایگاه دادهشان را از دست میدهند. این را از جواب یک انجمن کپی نکنید.
مصرفکنندهی پنهان دیگر، لاگ کانتینرهاست. در /etc/docker/daemon.json محدودشان کنید:
{
"log-driver": "json-file",
"log-opts": { "max-size": "10m", "max-file": "3" }
}
بعد Docker را ریاستارت کنید. این محدودیت فقط روی کانتینرهایی اعمال میشود که بعداً ساخته میشوند، پس کانتینرهای پرسروصدا را با docker compose up -d --force-recreate دوباره بسازید.
۵. لاگها و فایلهای فراموششده
فایلهای بزرگ را در هر جای دیسک پیدا کنید:
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
یافتههای همیشگی: یک backup.tar.gz مال شش ماه پیش در /root، یک دامپ پایگاه داده که کسی میخواست دانلودش کند، لاگ برنامهای که هیچوقت چرخانده نمیشود.
لاگی را که یک سرویس هنوز در آن مینویسد با rm پاک نکنید — خالیاش کنید:
truncate -s 0 /var/log/myapp/app.log
اگر قبلاً یکی را پاک کردهاید و فضا برنگشته، پردازهای هنوز بازش نگه داشته:
lsof +L1
سرویسی را که آنجا فهرست شده ریاستارت کنید و فضا برمیگردد.
وقتی پاکسازی کافی نیست
گاهی دادهها واقعاً لازماند — پایگاه دادهای که بزرگ میشود، فایلهای کاربران، یک فایل مدل. آنوقت راهحل صادقانه دیسک بیشتر است. ارتقای پلن دیسک را در جای خودش بزرگ میکند و همه چیز را نگه میدارد: Nano ۱۵ گیگابایت، Micro ۲۵ گیگابایت، Small ۳۵ گیگابایت و Medium ۴۵ گیگابایت دارد. سرور یک بار ریاستارت میشود. جزئیات در مستندات پلنها است.
یک چیز دیگر هم بیصدا فضا میخورد: فایل swap. اگر راهنمای swap را دنبال کردهاید، آن ۱ تا ۲ گیگابایت عمداً کنار گذاشته شده. و اگر بزرگترین مصرفکننده Docker است، راهنمای نصب Docker و راهنمای استکهای Compose نشان میدهند چطور ایمیجها را کنترل کنید.
عادتی که جلوی همهی اینها را میگیرد: ژورنال و لاگهای Docker را از روز اول محدود کنید. دو خط تنظیمات، و «دیسک پر است» تقریباً دیگر اتفاق نمیافتد.
نظرات
هنوز نظری نیست. اولین نفر باشید.