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

چرا swap پر است ولی RAM آزاد داریم؟ تشخیص فشار واقعی حافظه لینوکس

آموزش خواندن free و vmstat، تشخیص swap فعال و کاهش فشار حافظه سرور بدون خاموش‌کردن بی‌هدف swap.

انتشار:
توسط تیم فنی نت‌آرام
۶ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله چرا swap پر است ولی RAM آزاد داریم؟ تشخیص فشار واقعی حافظه لینوکس در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
در سرور مجازی ایران می‌بینید بخشی از swap استفاده شده، در حالی که RAM هنوز فضای قابل استفاده دارد. این وضعیت به‌تنهایی خرابی نیست. ممکن است در ساعت شلوغی قبلی، بعضی صفحه‌های کم‌استفاده حافظه به swap رفته باشند و پس از کم‌شدن بار همچنان آنجا مانده باشند. مسئله مهم‌تر این است که آیا اکنون داده‌ها مدام بین RAM و swap جابه‌جا می‌شوند و برنامه منتظر آن‌ها می‌ماند یا خیر.
swap بخشی از فضای ذخیره‌سازی است که سیستم می‌تواند برای صفحه‌هایی از حافظه استفاده کند. معمولاً دسترسی به آن از RAM کندتر است، اگرچه نوع دستگاه و بار مؤثرند. این راهنما کمک می‌کند مصرف قدیمی و بی‌حرکت را از فشار فعال جدا کنید و به‌جای خاموش‌کردن ناگهانی swap، علت کندی را درمان کنید.

۱. تصویر فعلی RAM و swap را ببینید

در ترمینال لینوکس اجرا کنید:
کد / دستورfree -h swapon --show
در خروجی free به available توجه کنید؛ این عدد برآورد حافظه قابل استفاده برای برنامه‌های جدید است و با ستون free که فقط حافظه کاملاً بلااستفاده را نشان می‌دهد فرق دارد. بخش Swap مقدار کل و مصرف‌شده را نمایش می‌دهد. swapon --show دستگاه یا فایل‌های swap فعال و اندازه آن‌ها را فهرست می‌کند. اگر swap فعال نیست، مصرف آن صفر است و باید دنبال علت دیگر کندی بگردید.
مثلاً اگر دو گیگابایت swap مصرف شده اما available زیاد است، فعلاً فقط می‌دانیم در گذشته یا حال صفحه‌هایی به swap رفته‌اند. این عدد از سرعت جابه‌جایی لحظه‌ای چیزی نمی‌گوید. اگر مقدار مصرف در زمان اوج رشد می‌کند، آن را همراه ساعت و وضعیت برنامه ثبت کنید؛ اندازه ثابت پس از رفع فشار لزوماً به صفر برنمی‌گردد.

۲. جابه‌جایی فعال را با چند نمونه بررسی کنید

کد / دستورvmstat 1 10
این فرمان ده نمونه تقریباً یک‌ثانیه‌ای می‌گیرد. ستون si مقدار swap ورودی به حافظه و so مقدار خروجی به swap را در بازه نشان می‌دهد؛ بسته به نسخه واحدها معمولاً KiB بر ثانیه‌اند. ردیف اول معمولاً میانگین از زمان بوت است، پس برای وضعیت کنونی به ردیف‌های بعدی توجه کنید. اعداد صفر یا نزدیک صفر در چند نمونه نشان می‌دهند در همان بازه جابه‌جایی محسوس ندیده‌اید، نه اینکه هیچ‌وقت مشکل نخواهید داشت.
اگر si و so برای مدت قابل توجه بالا هستند و هم‌زمان برنامه کند و حافظه available کم است، فشار حافظه و جابه‌جایی مداوم محتمل‌تر است. دوباره در ساعات اوج نمونه بگیرید. طبق توضیح Oracle درباره swap لینوکس، ماندن داده در swap بعد از برطرف‌شدن فشار می‌تواند طبیعی باشد و نرخ جابه‌جایی فعال شاخص مهم‌تری برای کندی است.

۳. فشار حافظه و علت‌های دیگر را کنار هم ببینید

در سیستم‌های دارای PSI، فرمان زیر زمان انتظار ناشی از فشار حافظه را نشان می‌دهد:
کد / دستورcat /proc/pressure/memory
اگر فایل وجود ندارد، کرنل یا تنظیم سرور ممکن است PSI را ارائه نکند. some زمانی را نشان می‌دهد که حداقل بخشی از کارها به دلیل فشار معطل بوده‌اند و full فشار شدیدتری را نشان می‌دهد؛ تغییر این اعداد را در بازه مشابه با کندی برنامه مقایسه کنید. یک عدد تنها تشخیص نهایی نیست.
برای بررسی شواهد کمبود حافظه در بوت فعلی:
کد / دستورsudo journalctl -k -b --no-pager | grep -i -E 'out of memory|oom-kill|killed process'
خروجی خالی لزوماً نبود همه مشکلات حافظه را ثابت نمی‌کند. اگر رخدادی هست، زمان و نام پردازش را با اختلال تطبیق دهید. CPU، دیسک و شبکه هم می‌توانند کندی ایجاد کنند؛ از روی swap مصرف‌شده برای ارتقای فوری منابع نتیجه نگیرید.

۴. مصرف‌کننده را پیدا و بار را کم کنید

کد / دستورps -eo pid,ppid,rss,comm --sort=-rss | head -n 16
این فهرست پردازش‌ها را بر اساس RSS تقریبی مرتب می‌کند؛ RSS به کیلوبایت است و مجموع ساده آن برای حافظه مشترک دقیق نیست. برای یک PID مشخص که از خروجی پیدا کرده‌اید، عدد واقعی را جایگزین کنید:
کد / دستورgrep -E 'Name|VmRSS|VmSwap' /proc/1234/status
VmSwap تنها بخشی از مصرف swap قابل انتساب به همان پردازش را نشان می‌دهد و برای صفحه‌های مشترک یا همه انواع حافظه شمارش کامل نیست. ممکن است پردازش پیش از خواندن فایل تمام شود. برای برنامه‌ای با چند worker، مصرف گروه و تعداد workerها را با هم ببینید. اگر یک سرویس سقف جداگانه دارد، راهنمای MemoryMax در systemd به شناسایی محدودیت آن کمک می‌کند.
اگر تعداد workerهای وب یا وظایف هم‌زمان بیش از ظرفیت است، با مدیر برنامه در ساعت مناسب تعداد را به اندازه‌ای کاهش دهید که هم مصرف و هم زمان پاسخ قابل قبول باشد. jobهای سنگین هم‌زمان، مانند گزارش‌گیری و بکاپ، را در زمان‌های جدا اجرا کنید. اگر مصرف یک فرایند پس از هر درخواست بدون برگشت رشد می‌کند، احتمال نشت حافظه را با لاگ و نسخه برنامه پیگیری کنید. وقتی بار سالم به‌طور مداوم از ظرفیت واقعی بیشتر است، افزایش RAM یا تقسیم بار بین سرورها راهکار پایدارتر است.

۵. آیا باید swap را خالی یا غیرفعال کنیم؟

برای صرفاً صفرشدن عدد مصرف، دستور swapoff را روی سرور فعال اجرا نکنید. این کار باید صفحه‌های لازم را به حافظه برگرداند و اگر ظرفیت کافی نباشد می‌تواند فشار شدید یا خطای حافظه ایجاد کند. پاک‌کردن cache سیستم نیز راه‌حل عمومی نیست و ممکن است عملکرد را بدتر کند. اگر تصمیم عملیاتی خاصی به تغییر swap نیاز دارد، ابتدا ظرفیت RAM، بار، محل swap، وابستگی‌ها و برنامه بازگشت را در محیط آزمایشی و پنجره نگه‌داری بررسی کنید.
مقدار vm.swappiness را می‌توان با sysctl vm.swappiness خواند. این گزینه ترجیح نسبی کرنل برای بازپس‌گیری برخی صفحه‌ها را تحت تأثیر قرار می‌دهد؛ عدد صفر به معنی ممنوعیت مطلق swap نیست. تغییر آن برای همه سرورها و بارها مناسب نیست و جای RAM کافی یا رفع نشت را نمی‌گیرد. مستند کرنل لینوکس معنی این تنظیم را توضیح می‌دهد.

۶. موفقیت را چطور بسنجیم؟

پس از اصلاح بار یا ظرفیت، در همان ساعت شلوغی free -h و vmstat 1 10 را دوباره بخوانید و زمان پاسخ سرویس را با قبل مقایسه کنید. کاهش جابه‌جایی مداوم، فضای available کافی و بهبود زمان پاسخ شواهد مفیدند؛ باقی‌ماندن مقداری swap مصرف‌شده به‌تنهایی شکست نیست. اگر با وجود این تغییرها کندی ادامه دارد، محدودیت حافظه سطح سرویس، خطای دیسک و علت‌های شبکه را جداگانه پیگیری کنید.
اشتراک‌گذاری:
لینکدینتلگرامایکس

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

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