"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 लॉग को सीमित कर दें। कॉन्फ़िगरेशन की दो लाइनें, और "डिस्क भर गई" लगभग होना बंद हो जाता है।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।