"No space left on device" কখনো সুবিধাজনক সময়ে আসে না। ডেটাবেস লেখা নেওয়া বন্ধ করে, apt আপডেট শেষ করতে পারে না, আর Docker ঠিক সেই ইমেজটাই টানতে অস্বীকার করে যেটা আপনার এখনই দরকার। ভালো খবর হলো, ছোট VPS-এ দোষী প্রায় সবসময় পাঁচটার মধ্যে একটা জিনিস, আর আপনি সেটা দুই মিনিটে খুঁজে পাবেন।
১. অবস্থা কতটা খারাপ?
df -h /
df -i /
প্রথম লাইন ব্যবহৃত জায়গা দেখায়। দ্বিতীয়টা inode দেখায় — যদি জায়গা ঠিকঠাক দেখায় অথচ inode ১০০%-এ পৌঁছে যায়, তাহলে আপনার লক্ষ লক্ষ খুদে ফাইল আছে (সেশন ফাইল, মেইল কিউ, ক্যাশ ফোল্ডার)। সমস্যা আলাদা, লক্ষণ একই।
২. কী বড় সেটা খুঁজুন
ট্রি ওপর থেকে দেখুন আর আকার অনুযায়ী সাজান:
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 চালালে আগে এখানে দেখুন। প্রতিটি ডিপ্লয়ের সাথে পুরোনো ইমেজ আর বিল্ড ক্যাশ জমতে থাকে:
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 দিয়ে আবার তৈরি করুন।
৫. লগ আর ভুলে যাওয়া ফাইল
ডিস্কের যেকোনো জায়গায় বড় ফাইল খুঁজুন:
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 গাইড মেনে থাকলে ওই ১–২ GB ইচ্ছে করেই রাখা। আর Docker সবচেয়ে বড় খরুচে হলে, Docker ইনস্টল গাইড আর Compose স্ট্যাক গাইড দেখায় কীভাবে ইমেজ নিয়ন্ত্রণে রাখবেন।
যে অভ্যাস এসব ঠেকায়: প্রথম দিনেই journal আর Docker লগে সীমা দিন। কনফিগারেশনের দুই লাইন, আর "ডিস্ক ভরে গেছে" প্রায় আর ঘটে না।
মন্তব্য
এখনো কোনো মন্তব্য নেই। প্রথম হোন।