وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

چرا tmpfs پر شده اما دیسک سرور هنوز فضای خالی دارد؟

آموزش مرحله‌به‌مرحله تشخیص فضای موقت پر، فایل باز، محدودیت RAM و تغییر امن مسیر موقت در سرور لینوکسی.

انتشار:
توسط تیم فنی نت‌آرام
۸ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله چرا tmpfs پر شده اما دیسک سرور هنوز فضای خالی دارد؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
برنامه هنگام استخراج فایل یا ساخت گزارش می‌گوید «فضای کافی وجود ندارد»، اما دیسک اصلی سرور هنوز چند گیگابایت خالی دارد. ممکن است برنامه فایل موقتش را در فضایی به نام tmpfs بسازد که سقف جداگانه‌ای دارد. خالی‌بودن دیسک اصلی این سقف را بیشتر نمی‌کند؛ مثل این است که انبار بزرگ شما جا داشته باشد، اما میز کوچک بسته‌بندی کاملاً پر شده باشد.
در این راهنما ابتدا محل واقعی خطا را پیدا می‌کنیم، بعد با توجه به نتیجه سراغ فایل بزرگ، فایل حذف‌شده‌ای که هنوز باز است یا محدودیت خود tmpfs می‌رویم. دستورها در ترمینال لینوکس سرور مجازی ایران یا سرور اختصاصی ایران اجرا می‌شوند. برای برخی گزارش‌ها دسترسی sudo لازم است. روی سرور عملیاتی قبل از توقف برنامه یا حذف هر فایل، کاربرد آن را بشناسید؛ پوشه موقت ممکن است فایل‌های در حال استفاده داشته باشد.

۱. اول مسیر واقعی برنامه را پیدا کنید

متن کامل خطا و نام مسیر را بخوانید. اگر مثلاً خطا به /tmp اشاره دارد، آن را با مسیر فایل برنامه خود مقایسه کنید. برنامه‌ها گاهی از متغیر محیطی TMPDIR یا تنظیم داخلی خود استفاده می‌کنند، نه الزاماً /tmp. در همان نشست یا اسکریپتی که برنامه اجرا می‌شود این دستور را بزنید:
کد / دستورprintenv TMPDIR
اگر چیزی چاپ نشد، یعنی این متغیر در همان نشست تنظیم نشده؛ این موضوع به‌تنهایی محل موقت برنامه را ثابت نمی‌کند. لاگ و تنظیمات همان برنامه یا سرویس را هم بخوانید. اگر مسیر خطا /tmp است، برای مقایسه وضعیت آن با دیسک اصلی از این دو دستور استفاده کنید:
کد / دستورdf -hT /tmp df -hT /
Type نوع فایل‌سیستم و Use% درصد مصرف ظرفیت را نشان می‌دهد. اگر ردیف /tmp نوع tmpfs و مصرف نزدیک ۱۰۰ درصد داشته باشد، ولی / فضای خالی داشته باشد، احتمالاً سقف فضای موقت مشکل‌ساز است. اگر /tmp روی همان ردیف / قرار گرفته، افزایش سقف tmpfs مربوط به آن نیست و باید همان فایل‌سیستم واقعی را بررسی کنید.
این دو دستور مکان دقیق اتصال را روشن‌تر می‌کنند:
کد / دستورfindmnt -T /tmp -o TARGET,SOURCE,FSTYPE,OPTIONS findmnt -M /tmp -o TARGET,SOURCE,FSTYPE,OPTIONS
اولی فایل‌سیستمی را نشان می‌دهد که مسیر را پوشش می‌دهد؛ دومی فقط اتصال دقیق روی خود /tmp را می‌جوید. اگر دستور دوم چیزی چاپ نکرد، لزوماً خطا نیست: ممکن است /tmp فقط پوشه‌ای در فایل‌سیستم دیگری باشد. برای /var/tmp یا /dev/shm همین دستورها را با مسیر واقعی جایگزین کنید. هیچ‌کدام را از پیش tmpfs فرض نکنید؛ تنظیم توزیع‌ها و سرویس‌ها متفاوت است.

۲. حجم تمام شده یا تعداد فایل‌ها؟

کد / دستورdf -i /tmp
ستون IUse% مصرف تعداد جایگاه فایل یا inode را نشان می‌دهد. اگر ظرفیت حجمی آزاد است اما تعداد inode به سقف رسیده، ممکن است تعداد زیادی فایل کوچک ساخته شده باشد. در آن صورت راهنمای پیدا کردن مصرف inode مسیر جداگانه‌ای دارد. اگر هر دو مقدار طبیعی‌اند، سهمیه کاربر، مسیر واقعی خطا و محدودیت خود برنامه یا کانتینر را نیز بررسی کنید؛ پیام مشابه همیشه به معنای پرشدن tmpfs نیست.
tmpfs داده را در حافظه مجازی نگه می‌دارد و بسته به تنظیمات و پشتیبانی سیستم می‌تواند از swap هم استفاده کند. سقف آن به معنی رزرو فوری همان مقدار RAM نیست؛ با زیاد شدن داده، مصرف حافظه هم تغییر می‌کند. این گزارش را ببینید:
کد / دستورfree -h
به available برای تخمین حافظه قابل استفاده و به مقدار آزاد swap توجه کنید. پایین‌بودن حافظه یا استفاده سنگین از swap، همراه با کندی، نشانه خوبی برای بزرگ‌کردن فوری tmpfs نیست. طبق مستندات هسته لینوکس، محتوای tmpfs پس از unmount از بین می‌رود؛ از آن برای تنها نسخه داده مهم یا بکاپ استفاده نکنید.

۳. کدام پوشه فضا را گرفته است؟

پس از اطمینان از مسیر، برای دیدن حجم تقریبی زیرپوشه‌های همان فایل‌سیستم اجرا کنید:
کد / دستورsudo du -xhd1 /tmp
گزینه -x مانع عبور به فایل‌سیستم‌های دیگر می‌شود و -d1 فقط یک سطح را خلاصه می‌کند. اگر پوشه‌ای حجم زیادی دارد، مسیر واقعی همان پوشه را جداگانه بررسی کنید. نام، مالک و زمان تغییر فایل‌ها کمک می‌کنند صاحب مصرف را پیدا کنید:
کد / دستورsudo ls -lah /tmp
ممکن است یک استخراج، اسکن یا ساخت فایل خروجی بزرگ هنوز در حال اجرا باشد. در این حالت اول کار را در خود برنامه تمام یا طبق راهنمای همان برنامه متوقف کنید. اگر برنامه ابزار پاک‌سازی فایل موقت خودش را دارد، از همان استفاده کنید. فقط فایل یا پوشه‌ای را حذف کنید که تعلقش، پایان کار و بی‌نیازبودن آن را تأیید کرده‌اید؛ پاک‌کردن همه /tmp یا حذف خودکار همه فایل‌های قدیمی می‌تواند کارهای فعال کاربران را خراب کند.
اگر df مصرف زیادی نشان می‌دهد ولی مجموع du کوچک است، ممکن است فایل حذف شده اما هنوز توسط یک فرایند باز باشد. اگر ابزار lsof نصب است، این گزارش سراسری را بخوانید:
کد / دستورsudo lsof -nP +L1
نام برنامه، PID و مسیر فایل‌های حذف‌شده را با مسیر و زمان خطا تطبیق دهید؛ این فهرست ممکن است فایل‌های فایل‌سیستم‌های دیگر را هم نشان دهد. بستن درست فایل یا پایان کنترل‌شده همان کار می‌تواند فضا را آزاد کند. اگر متعلق به سرویسی است، پیش از راه‌اندازی مجدد اثر قطع سرویس و روش توقف امن آن را مشخص کنید؛ از کشتن همه پردازش‌ها یا دست‌کاری فایل‌های /proc خودداری کنید. پس از پایان کار دوباره df -hT /tmp را اجرا کنید.

۴. اگر یک کار به فضای موقت بزرگ نیاز دارد

برای کاری که از TMPDIR پشتیبانی می‌کند، می‌توانید یک پوشه خصوصی روی فایل‌سیستم دارای فضای کافی بسازید و فقط همان اجرای برنامه را به آن هدایت کنید. ابتدا فضای مسیر خانگی را ببینید:
کد / دستورdf -hT "$HOME"
اگر فضای کافی وجود دارد، با همان کاربری که برنامه را اجرا می‌کند یک پوشه جدید بسازید:
کد / دستورmkdir -m 700 "$HOME/server-work-tmp"
اگر پوشه از قبل وجود دارد، دستور با خطا متوقف می‌شود؛ پیش از استفاده مالک، مجوز و محتوای آن را بررسی کنید. عدد ۷۰۰ دسترسی پوشه را به صاحبش محدود می‌کند. حالا در همان نشست، یک فایل آزمایشی امن در آن بسازید:
کد / دستورTMPDIR="$HOME/server-work-tmp" mktemp
دستور مسیر فایل جدید را چاپ می‌کند. همان مسیر را یادداشت کنید و فقط همان فایل آزمایشی خودتان را پس از بررسی حذف کنید. سپس برنامه مورد نظر را با پیشوند TMPDIR="$HOME/server-work-tmp" اجرا کنید؛ این تغییر فقط برای همان اجرا و برنامه‌های فرزندش است. خود فرمان برنامه را مطابق مستنداتش وارد کنید. بعضی برنامه‌ها این متغیر را نادیده می‌گیرند یا تنظیم اختصاصی دارند، پس خروجی و محل فایل موقت را تأیید کنید. فایل موقت ممکن است اطلاعات حساس داشته باشد؛ آن را داخل پوشه عمومی سایت قرار ندهید.
برای سرویس systemd، اجرای دستور در ترمینال متغیر سرویس را عوض نمی‌کند. ابتدا تنظیمات و کاربر واقعی سرویس را ببینید:
کد / دستورsystemctl show NAME.service -p User -p Environment -p PrivateTmp
به‌جای NAME.service نام واقعی را بگذارید. اگر PrivateTmp=yes باشد، مسیر قابل مشاهده سرویس با نشست عادی یکسان نیست؛ این رفتار در راهنمای systemd توضیح داده شده است. مسیر اختصاصی، مجوز کاربر سرویس و تنظیم محیط را طبق مستندات برنامه و روش نصب خود تنظیم کنید و اثر راه‌اندازی مجدد را در نظر بگیرید. اگر برنامه داخل کانتینر است، بررسی را داخل همان کانتینر و تنظیم mount آن تکرار کنید.

۵. چه زمانی سقف tmpfs را تغییر دهیم؟

اگر مصرف عادی برنامه واقعاً از سقف فعلی بیشتر است و RAM و swap کافی دارید، می‌توانید بعد از برنامه‌ریزی محدودیت را بالا ببرید. ابتدا خروجی هر دو دستور findmnt و df را ذخیره کنید و مطمئن شوید خود /tmp یک mount با نوع tmpfs است. مقدار فعلی و تنظیماتش را یادداشت کنید. نمونه زیر فقط وقتی مناسب است که سقف فعلی از ۲ گیگابایت کمتر باشد و ظرفیت حافظه سرور برای این تغییر کافی باشد:
کد / دستورsudo mount -o remount,size=2G /tmp
این دستور اتصال موجود را با سقف نمونه ۲ گیگابایت دوباره تنظیم می‌کند؛ عدد را بر اساس بار واقعی انتخاب کنید. افزایش سقف، RAM جدید به سرور اضافه نمی‌کند و اگر مصرف به حافظه موجود فشار بیاورد می‌تواند برنامه‌های دیگر را کند یا متوقف کند. این تغییر معمولاً موقتی است و ممکن است پس از راه‌اندازی مجدد به تنظیم قبلی برگردد. برای تنظیم پایدار ابتدا مشخص کنید اتصال را fstab، واحد systemd یا ابزار دیگری مدیریت می‌کند؛ تغییر نسخه و روش نصب مهم است. تنظیم قبلی را نگه دارید و تغییر را ابتدا در محیط آزمایشی امتحان کنید.
اگر دستور خطا داد، پیام را نگه دارید و مسیر و نوع mount را دوباره بخوانید؛ آن را روی مسیر نامطمئن یا فایل‌سیستم اصلی تکرار نکنید. کاهش سقف به کمتر از مصرف فعلی نیز مجاز نیست. اگر تغییر باعث فشار حافظه شد، پس از کاهش امن مصرف، همان سقف قبلیِ ثبت‌شده را با روش متناسب با سیستم برگردانید.

۶. نتیجه را با خود برنامه امتحان کنید

دوباره df -hT و df -i را برای مسیر واقعی بگیرید، سپس همان کار شکست‌خورده را با حجم کنترل‌شده اجرا کنید. موفقیت زمانی روشن است که برنامه بدون خطا کار را تمام کند، خروجی سالم باشد و مصرف فضای موقت بی‌وقفه بالا نرود. اگر مشکل فقط در سرویس یا کانتینر باقی است، محیط و مسیر موقت همان سرویس را بررسی کنید. برای جلوگیری از تکرار، به‌جای پاک‌سازی سراسری، مدت نگهداری فایل‌های موقت همان برنامه و هشدار مصرف mount مربوط را تنظیم کنید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام