"No space left on device" هېڅکله په مناسب وخت نه راځي. ډېټابېس لیکل منل بندوي، apt تازه کول نشي بشپړولی، او Docker له راښکلو ډډه کوي، هغه هم د هماغه image چې همدا اوس ورته اړتیا لرئ. ښه خبر دا دی: په کوچني VPS کې ګناهکار تقریباً تل له پنځو شیانو څخه یو وي، او په دوو دقیقو کې یې مومئ.
۱. حالت څومره خراب دی؟
df -h /
df -i /
لومړۍ کرښه کارول شوی ځای ښيي. دوهمه inodes ښيي — که inodes سل سلنې ته ورسېږي په داسې حال کې چې ځای سم ښکاري، نو تاسو میلیونونه وړوکي فایلونه لرئ (د سیشن فایلونه، د برېښنالیک کتار، د کش فولډر). بېله ستونزه، ورته نښه.
۲. ومومئ چې څه لوی دي
ونه له پاسه وګورئ او د اندازې له مخې یې ترتیب کړئ:
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 journal هغه څه دي چې خلک حیرانوي — که پرې یې ږدئ، څو ګیګابایټه لوی کېدای شي. د تل لپاره د محدودولو لپاره په /etc/systemd/journald.conf کې SystemMaxUse=200M وټاکئ او systemctl restart systemd-journald وچلوئ.
۴. د Docker پاتې شوني
که Docker چلوئ، لومړی دلته وګورئ. زاړه image-ونه او build کش د هر ډیپلای سره راټولېږي:
docker system df
docker image prune -a
docker builder prune
docker image prune -a هغه image-ونه ړنګوي چې هېڅ چلېدونکی کانټینر یې نه کاروي. معمولاً همدا غواړئ، خو راتلونکی ډیپلای به یې بیا راښکاږي.
خطرناک یې 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 په مرسته بیا جوړ کړئ.
۵. لاګونه او هېر شوي فایلونه
د ډیسک په هر ځای کې لوی فایلونه ومومئ:
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
معمولي موندنې: په /root کې شپږ میاشتې زوړ backup.tar.gz، د ډېټابېس ډمپ چې چا غوښتل ډاونلوډ یې کړي، د اپلیکېشن لاګ چې هېڅکله نه ګرځول کېږي.
هغه لاګ چې یو سرویس لا هم پکې لیکي، په rm مه ړنګوئ — خالي یې کړئ:
truncate -s 0 /var/log/myapp/app.log
که مو یو دمخه ړنګ کړی او ځای بېرته نه دی راغلی، یوه پروسه لا هم خلاص ساتي:
lsof +L1
هلته ښودل شوی سرویس بیا پیل کړئ او ځای بېرته راځي.
کله چې پاکول بس نه وي
ځینې وخت ډېټا واقعاً اړینه وي — وده کوونکی ډېټابېس، د کاروونکو اپلوډونه، د ماډل فایل. بیا صادقانه حل ډېر ډیسک دی. د پلان لوړول ډیسک په خپل ځای لوی کوي او هر څه ساتي: Nano ۱۵ GB، Micro ۲۵ GB، Small ۳۵ GB او Medium ۴۵ GB لري. سرور یو ځل بیا پیلېږي. جزیات د پلانونو په اسنادو کې دي.
یو بل شی چې په چوپه ځای خوري: د swap فایل. که مو زموږ د swap لارښود تعقیب کړی وي، هغه ۱–۲ GB په قصد ساتل شوي. او که Docker تر ټولو لوی مصرفوونکی وي، د Docker نصبولو لارښود او د Compose سټیک لارښود ښيي چې image-ونه څنګه تر کنټرول لاندې وساتئ.
هغه عادت چې دا ټول مخنیوی کوي: journal او د Docker لاګونه له لومړۍ ورځې محدود کړئ. دوه کرښې تنظیمات، او "ډیسک ډک شو" تقریباً نور نه پېښېږي.
تبصرې
لا تبصرې نشته. لومړی اوسئ.