"No space left on device" کبھی مناسب وقت پر نہیں آتا۔ ڈیٹابیس لکھنا قبول کرنا بند کر دیتا ہے، apt اپ ڈیٹ مکمل نہیں کر پاتا، اور Docker عین وہی امیج کھینچنے سے انکار کر دیتا ہے جس کی آپ کو ابھی ضرورت ہے۔ اچھی خبر یہ ہے کہ چھوٹے 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 پرانے کرنل بھی صاف کرتا ہے۔ systemd کا journal وہ چیز ہے جو لوگوں کو حیران کرتی ہے — اسے یوں ہی چھوڑ دیں تو یہ کئی گیگابائٹ تک بڑھ سکتا ہے۔ اسے مستقل طور پر محدود کرنے کے لیے /etc/systemd/journald.conf میں SystemMaxUse=200M رکھیں اور 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
عام طور پر ملنے والی چیزیں: /root میں چھ مہینے پرانی backup.tar.gz، کسی کا ڈاؤن لوڈ کرنے کا ارادہ رکھنے والا ڈیٹابیس ڈمپ، ایسی ایپ لاگ جو کبھی روٹیٹ نہیں ہوتی۔
جس لاگ میں کوئی سروس ابھی لکھ رہی ہو اسے 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 لاگز کو محدود کر دیں۔ کنفیگریشن کی دو لائنیں، اور "ڈسک بھر گئی" تقریباً ہونا بند ہو جاتا ہے۔
تبصرے
ابھی کوئی تبصرہ نہیں۔ پہلے بنیں۔