رسالة "No space left on device" لا تأتي أبدًا في وقت مناسب. تتوقف قاعدة البيانات عن قبول الكتابة، ولا يستطيع apt إكمال تحديث، ويرفض Docker سحب الصورة التي تحتاجها الآن تحديدًا. الخبر الجيد: على VPS صغير يكون السبب غالبًا واحدًا من خمسة أشياء، وتجده في دقيقتين.
1. ما مدى سوء الوضع؟
df -h /
df -i /
السطر الأول يُظهر المساحة المستخدمة. والثاني يُظهر الـinodes — إذا وصلت إلى 100% بينما تبدو المساحة جيدة، فلديك ملايين الملفات الصغيرة جدًا (ملفات جلسات، طابور بريد، مجلد ذاكرة مؤقتة). مشكلة مختلفة، والعَرَض نفسه.
2. اعثر على ما هو كبير
امشِ في الشجرة من الأعلى ورتّب حسب الحجم:
du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15
الخيار -x يبقى على نظام ملفات واحد، فلا يتوه داخل /proc. ثم ادخل إلى الأكبر. للتصفح التفاعلي، ncdu أريح بكثير:
apt install -y ncdu
ncdu -x /
الأسهم للتنقل، وd للحذف. انتبه مع الأخير.
3. المكاسب السريعة
هذه آمنة على أي خادم Ubuntu أو Debian:
apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M
apt autoremove يزيل أيضًا الأنوية القديمة. أما journal الخاص بـsystemd فهو ما يفاجئ الناس — إن تُرك دون حد قد يكبر إلى عدة غيغابايتات. لتقييده نهائيًا، اضبط SystemMaxUse=200M في /etc/systemd/journald.conf ثم نفّذ systemctl restart systemd-journald.
4. بقايا 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.
5. السجلات والملفات المنسية
اعثر على الملفات الكبيرة في أي مكان على القرص:
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 فيها 15 GB وMicro فيها 25 GB وSmall فيها 35 GB وMedium فيها 45 GB. يُعاد تشغيل الخادم مرة واحدة. التفاصيل في توثيق الخطط.
شيء آخر يستهلك المساحة بصمت: ملف الـswap. إن اتبعت دليل الـswap فهذه الـ1–2 GB محجوزة عن قصد. وإن كان Docker هو المستهلك الأكبر، فإن دليل تثبيت Docker ودليل مجموعات Compose يوضحان كيف تُبقي الصور تحت السيطرة.
العادة التي تمنع كل هذا: قيّد الـjournal وسجلات Docker من اليوم الأول. سطران من الإعدادات، و"القرص ممتلئ" يكاد يتوقف عن الحدوث.
التعليقات
لا تعليقات بعد. كن الأول.