مقاله 10 / رفع مشکل
پر شدن دیسک سرور لینوکس؛ تشخیص علت و آزادسازی کنترل‌شده فضا
مشخصات پیشنهادی انتشار
- عنوان سئو
- پر شدن دیسک سرور لینوکس؛ تشخیص و رفع مشکل | نگهبان وب
- توضیح متا
- با df و du علت پر شدن دیسک سرور لینوکس را پیدا کنید؛ تفاوت inode، لاگ، داده و فضای Docker را بشناسید و برای آزادسازی کنترل‌شده تصمیم بگیرید.
- مسیر پیشنهادی
- /blog/linux-disk-full
- عبارت اصلی
- پر شدن دیسک سرور لینوکس
- تصویر
- linux-disk-full.webp
- یادداشت انتشار
- تصویر را در CMS بارگذاری و تاریخ واقعی انتشار و URL تصویر را ثبت کنید.
پر شدن دیسک می‌تواند ثبت لاگ، اجرای برنامه، ذخیره فایل و حتی نوشتن دیتابیس را مختل کند. واکنش سریع به معنی حذف سریع هر فایل بزرگ نیست. ابتدا باید بفهمید کدام فایل‌سیستم پر شده، آیا مشکل ظرفیت بایت است یا inode و کدام سرویس مسئول رشد است.
این راهنما از فرمان‌های تشخیصی شروع می‌کند. پیش از هر حذف، کاربرد داده و مسیر بازیابی آن را مشخص کنید. حذف فایل دیتابیس، volume یا بکاپ بدون شناخت می‌تواند یک کمبود فضا را به از دست رفتن داده تبدیل کند.
فرمان df فضای فایل‌سیستم‌های mountشده را نشان می‌دهد. گزینه نمایش inode نیز کمک می‌کند وضعیتی را پیدا کنید که تعداد زیادی فایل کوچک، ظرفیت شمارشی فایل‌سیستم را مصرف کرده‌اند. در این حالت ممکن است هنوز فضای بایتی آزاد باشد اما ساخت فایل جدید شکست بخورد.
df -h
df -iخروجی را براساس mount مربوط به داده مشکل‌دار بخوانید. پر شدن یک volume مستقل الزاماً در ظرفیت ریشه دیده نمی‌شود. همچنین برخی مسیرها داخل کانتینر به فضای میزبان یا volume دیگری نگاشت می‌شوند؛ نقشه ذخیره‌سازی را با مسیر واقعی تطبیق دهید.
قدم دوم: محل رشد را پیدا کنید
با بررسی مرحله‌ای از پوشه‌های اصلی به زیرپوشه‌ها برسید. برای نمونه روی بسیاری از سرورها می‌توان از مسیر /var شروع کرد. گزینه x در du از عبور به فایل‌سیستم‌های دیگر جلوگیری می‌کند و d عمق نمایش را محدود می‌کند.
sudo du -xhd1 /var
sudo journalctl --disk-usage
docker system dfفرمان آخر فقط روی میزبان دارای Docker و با دسترسی مناسب کاربرد دارد. پیمایش du می‌تواند روی دیسک شلوغ بار خواندن ایجاد کند؛ آن را بی‌وقفه تکرار نکنید. خطاهای دسترسی و فایل‌های در حال تغییر نیز می‌توانند نتیجه را ناقص کنند.
تفاوت df و du از کجا می‌آید؟
گاهی df مصرف بیشتری نسبت به جمع فایل‌های قابل مشاهده نشان می‌دهد. یکی از علت‌ها فایلی است که حذف شده اما فرایندی هنوز آن را باز نگه داشته است. فایل‌سیستم، snapshot، فضای رزروشده و mountها هم می‌توانند در اختلاف نقش داشته باشند.
پس صرف اختلاف این دو خروجی، مجوز حذف بیشتر نیست. ابتدا فایل‌های باز حذف‌شده و وضعیت سرویس مسئول را بررسی کنید. برای آزاد شدن آن فضا ممکن است بازگشایی کنترل‌شده فایل یا اقدام روی فرایند لازم باشد؛ restart باید با شناخت اثر روی خدمت انجام شود.
چهار منبع رایج مصرف را جدا بررسی کنید
| منبع | چه چیزی را بررسی کنیم؟ | اقدام پایدار |
|---|---|---|
| لاگ برنامه و سیستم | نرخ تولید، تکرار خطا و دوره نگهداری | اصلاح علت خطا و چرخش لاگ |
| image و cache ساخت | نسخه‌های موردنیاز و داده قابل بازسازی | سیاست پاک‌سازی با دامنه مشخص |
| بکاپ محلی | انتقال موفق و نیاز به نسخه‌های تاریخی | نگهداری مستقل و retention روشن |
| داده واقعی برنامه | رشد دیتابیس و فایل کاربران | ظرفیت‌سنجی و معماری ذخیره مناسب |
پوشه‌ای که بزرگ است الزاماً زائد نیست. رشد دیتابیس ممکن است کاملاً طبیعی باشد و نیاز به افزایش ظرفیت داشته باشد. در مقابل، تولید چند گیگابایت لاگ تکراری در ساعت معمولاً نشانه مشکلی است که حذف موقت فایل آن را حل نمی‌کند.
در Docker چه چیزی را نباید کورکورانه پاک کرد؟
image، build cache، کانتینر متوقف و volume نقش‌های متفاوتی دارند. volume می‌تواند داده دائمی برنامه یا دیتابیس باشد. اجرای دستورهای پاک‌سازی گسترده با گزینه حذف volume، بدون فهرست و تأیید داده‌ها، روش مناسبی برای مدیریت رخداد نیست.
حتی حذف imageهای قدیمی باید با نیاز بازگشت نسخه هماهنگ باشد. اگر نسخه قبل از میزبان و registry حذف شود، برگشت اضطراری سخت‌تر می‌شود. پیش از پاک‌سازی، اقلام موردنیاز deployment و نسخه‌های نگه‌داشتنی را مشخص کنید.
آزادسازی را با کمترین اثر انجام دهید
ابتدا داده‌ای را انتخاب کنید که مالک و قابلیت بازسازی آن روشن است. اگر لاگ عامل اصلی است، از روش چرخش یا نگهداری پشتیبانی‌شده همان سرویس استفاده کنید. تغییر مستقیم فایل‌های داخلی دیتابیس یا موتور کانتینر می‌تواند ناسازگاری ایجاد کند.
پس از اقدام، ظرفیت آزاد، سلامت برنامه و ادامه ثبت داده را بررسی کنید. اگر فضا دوباره سریع پر می‌شود، نرخ رشد را ثبت کنید و علت را برطرف کنید. انتقال مشکل به یک دیسک بزرگ‌تر بدون سیاست نگهداری، فقط زمان تکرار را تغییر می‌دهد.
هشدار را براساس ظرفیت و روند بسازید
درصد مصرف را کنار فضای آزاد مطلق و نرخ رشد ببینید. ده درصد فضای خالی روی دیسک کوچک و بزرگ معنای یکسانی ندارد. برای inode، حجم لاگ و آخرین انتقال بکاپ نیز شاخص داشته باشید و مسئول پاسخ را مشخص کنید.
خدمات مانیتورینگ می‌تواند این شاخص‌ها را به هشدار قابل اقدام تبدیل کند. گزارش رخداد باید علت، داده حذف یا منتقل‌شده، نتیجه بررسی سلامت و اقدام پیشگیرانه را ثبت کند.
پرسش‌های رایج
آیا خالی کردن لاگ همیشه بی‌خطر است؟
خیر. ممکن است شواهد تشخیص از بین برود یا روش انتخابی با سرویس سازگار نباشد. سیاست نگهداری و روش چرخش را بررسی کنید.
چرا با وجود فضای آزاد، فایل ساخته نمی‌شود؟
inode، سهمیه، محدودیت فایل‌سیستم یا مجوزها را هم بررسی کنید. پیام دقیق خطا مسیر تشخیص را روشن می‌کند.
اگر خدمت مختل شده، درخواست رفع مشکل دیسک سرور را با خروجی خلاصه df، زمان شروع و سرویس‌های آسیب‌دیده ثبت کنید.
