ההודעה "No space left on device" אף פעם לא מגיעה בזמן נוח. מסד הנתונים מפסיק לקבל כתיבות, apt לא מצליח לסיים עדכון, ו-Docker מסרב למשוך בדיוק את ה-image שאתם צריכים עכשיו. החדשות הטובות: ב-VPS קטן האשם הוא כמעט תמיד אחד מחמישה דברים, ומוצאים אותו בשתי דקות.
1. כמה המצב גרוע?
df -h /
df -i /
השורה הראשונה מראה את המקום התפוס. השנייה מראה inodes — אם ה-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, תסתכלו כאן קודם. images ישנים ומטמון בנייה נערמים בכל deploy:
docker system df
docker image prune -a
docker builder prune
docker image prune -a מוחק images שאף קונטיינר פעיל לא משתמש בהם. בדרך כלל זה מה שאתם רוצים, אבל ה-deploy הבא ימשוך אותם שוב.
המסוכנת היא docker system prune -a --volumes. ה-volumes מחזיקים את הנתונים שלכם, ו-volume שמחובר לקונטיינר עצור נחשב לא בשימוש. ככה אנשים מאבדים מסדי נתונים. אל תדביקו את זה מתשובה בפורום.
הזולל הנסתר השני הוא הלוגים של הקונטיינרים. הגבילו אותם ב-/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 stacks מראים איך לשמור על ה-images בשליטה.
ההרגל שמונע את כל זה: הגבילו את ה-journal ואת הלוגים של Docker מהיום הראשון. שתי שורות הגדרה, ו"הדיסק מלא" כמעט מפסיק לקרות.
תגובות
אין עדיין תגובות. היו הראשונים.