چگونه مصرف RAM را در Linux بررسی کنیم؟

پاسخ سریع

برای ارزیابی حافظه به available، Swap، Processهای پرمصرف و رخدادهای OOM نگاه کنید؛ عدد free به‌تنهایی کافی نیست.

Linux حافظه بدون استفاده را برای Cache فایل به کار می‌برد و در صورت نیاز آزاد می‌کند. ستون available تخمین مناسب‌تری از فضای قابل استفاده بدون Swap سنگین است.

اول نشانه را دقیق تعریف کنید

عبارت‌هایی مانند «کند است»، «وصل نمی‌شود» یا «RAM پر است» برای شروع کافی‌اند اما برای حل مشکل نه. زمان شروع، کاربران درگیر، Endpoint یا Process، پیام خطای دقیق و آخرین تغییر موفق را ثبت کنید. یک Timeline کوتاه معمولاً نصف مسیر تشخیص را روشن می‌کند.

همان رفتار را از یک مسیر دوم بازتولید کنید و تفاوت حالت سالم و خراب را بنویسید. اگر مشکل تصادفی است، به‌جای حدس‌زدن نمونه‌برداری دوره‌ای از متریک و Log را فعال کنید تا لحظه بعدی شواهد از بین نرود.

علت‌های محتمل را لایه‌بندی کنید

از بیرون به داخل حرکت کنید: DNS و Route، Firewall و Port، Process و Service، منابع سیستم، Dependencyها و در نهایت منطق برنامه. این ترتیب از دست‌کاری برنامه برای مشکلی که در شبکه است جلوگیری می‌کند.

در هر لایه یک آزمون کم‌خطر انتخاب کنید که فرضیه را رد یا تأیید کند. نتیجه «کار نکرد» کافی نیست؛ فرمان، زمان و خروجی را ثبت کنید تا بتوانید مسیر را بازسازی و با همکار دیگری بررسی کنید.

• free -h نمای کلی می‌دهد.
• ps یا top مالک مصرف را مشخص می‌کند.
• vmstat نرخ swap-in و swap-out را نشان می‌دهد.

جمع‌آوری شواهد

ابتدا روند زمانی را ببینید، سپس Processهای بزرگ و limit سرویس را بررسی کنید. افزایش مداوم RSS می‌تواند Leak باشد؛ رشد Page Cache لزوماً مشکل نیست.

قبل از Restart یا Kill، وضعیت Processها، مصرف منابع، Connectionها و Log همان بازه را ذخیره کنید. ساعت Client و Server را تطبیق دهید؛ اختلاف زمان می‌تواند رویدادهای مرتبط را در چند Log از هم جدا نشان دهد.

1free -h2ps aux --sort=-%mem | head3vmstat 1 104journalctl -k | grep -i -E "oom|out of memory"

خروجی ابزارها را چطور بخوانیم؟

به یک عدد منفرد تکیه نکنید. CPU بالا همراه latency بالا معنای متفاوتی از CPU بالا با پاسخ سریع دارد؛ دیسک پر با inode آزاد با دیسکی که inode آن تمام شده یکسان نیست؛ و Connection refused با timeout مسیر عیب‌یابی متفاوتی دارد.

شاخص‌ها را در یک بازه و کنار Traffic، Deploy و Jobهای زمان‌بندی‌شده ببینید. به‌جای میانگین، p95، پیک و روند را بررسی کنید. همبستگی علت را ثابت نمی‌کند، اما فرضیه‌های شما را اولویت‌بندی می‌کند.

اصلاح کم‌خطر و مرحله‌ای

پس از یافتن محتمل‌ترین علت، کوچک‌ترین تغییر قابل بازگشت را اعمال کنید و همان معیار اولیه را دوباره بسنجید. اگر چند تنظیم را با هم تغییر دهید، حتی در صورت رفع مشکل نمی‌دانید کدام مورد مؤثر بوده و احتمال رگرسیون بیشتر می‌شود.

برای تغییر حساس، Backup یا Snapshot، نفر دوم و زمان بازگشت تعریف کنید. اگر سرویس چند نمونه دارد، اصلاح را ابتدا روی یک نمونه اجرا و رفتار آن را با گروه کنترل مقایسه کنید.

چرا راه‌حل‌های فوری گاهی بدتر می‌کنند؟

اجرای drop_caches برای «آزادکردن RAM» معمولاً درمان نیست و می‌تواند I/O بعدی را کندتر کند.

Restart، پاک‌کردن Cache، افزایش Timeout یا افزودن منابع ممکن است موقتاً نشانه را پنهان کند. اگر مجبور به اقدام اضطراری هستید، پیش از آن شواهد حداقلی بگیرید و پس از پایدارشدن سرویس تحلیل ریشه‌ای را در یک Incident review کامل کنید.

بعد از رفع مشکل

سلامت را فقط با ناپدیدشدن خطا تأیید نکنید؛ درخواست واقعی، latency، نرخ خطا و backlog را تا یک بازه کافی پایش کنید. سپس Alertی بسازید که قبل از رسیدن به همان وضعیت هشدار دهد.

علت، اثر، شواهد، اقدام اصلاحی و پیشگیری را کوتاه و بدون سرزنش ثبت کنید. اگر خطا با یک Runbook قابل تشخیص بود، آن را به Monitoring یا Automation تبدیل کنید تا دفعه بعد زمان بازیابی کمتر شود.

پرسش‌های مهمی که قبل از اقدام باید جواب دهید

برای اینکه پاسخ «چگونه مصرف RAM را در Linux بررسی کنیم؟» فقط در حد اطلاعات عمومی نماند، ابتدا وضعیت فعلی خود را با عدد توصیف کنید: نسخه سیستم‌عامل یا نرم‌افزار، تعداد کاربر هم‌زمان، مصرف معمول و اوج منابع، حجم و رشد داده، محدودیت شبکه و بیشترین قطعی قابل قبول. بدون این اطلاعات ممکن است توصیه‌ای که از نظر فنی درست است، برای محیط شما انتخاب مناسبی نباشد.

دو سؤال بعدی مستقیماً از نکات این موضوع می‌آیند: «free -h نمای کلی می‌دهد.» در زیرساخت شما چگونه اندازه‌گیری یا تأیید می‌شود؟ و «ps یا top مالک مصرف را مشخص می‌کند.» چه اثری روی کاربر، هزینه یا مسیر بازیابی دارد؟ پاسخ را در قالب شواهدی مانند خروجی فرمان، نمودار متریک، نتیجه آزمون یا مستند ارائه‌دهنده ثبت کنید؛ اتکا به حافظه و حدس برای تصمیم عملیاتی کافی نیست.

یک برنامه عملی کم‌ریسک

کار را با ثبت وضعیت فعلی و یک معیار موفقیت آغاز کنید. سپس پیشنهاد اصلی این راهنما را در کوچک‌ترین محیط نماینده اجرا کنید: ابتدا روند زمانی را ببینید، سپس Processهای بزرگ و limit سرویس را بررسی کنید. افزایش مداوم RSS می‌تواند Leak باشد؛ رشد Page Cache لزوماً مشکل نیست. نتیجه را در حالت عادی و در یک سناریوی خطا یا فشار کنترل‌شده بسنجید. اگر معیار بهتر نشد، به‌جای افزودن تغییرات بیشتر، فرض اولیه را بازبینی کنید.

پیش از اعمال تغییر در سرویس اصلی، روش بازگشت، مسئول تصمیم و زمان توقف را روشن کنید. این هشدار را نیز به‌عنوان شرط توقف در نظر بگیرید: اجرای drop_caches برای «آزادکردن RAM» معمولاً درمان نیست و می‌تواند I/O بعدی را کندتر کند. پس از اجرا، نتیجه، نسخه‌ها و تنظیمات مؤثر را مستند کنید و یک زمان بازبینی تعیین کنید؛ تغییر بدون پایش ممکن است امروز سالم به نظر برسد اما در پیک بعدی شکست بخورد.

• free -h نمای کلی می‌دهد.
• ps یا top مالک مصرف را مشخص می‌کند.
• vmstat نرخ swap-in و swap-out را نشان می‌دهد.

چک‌لیست عیب‌یابی

برای حل «چگونه مصرف RAM را در Linux بررسی کنیم؟» این ترتیب را حفظ کنید: تعریف نشانه، ثبت Timeline، بررسی لایه‌ها، جمع‌آوری شواهد، یک تغییر قابل بازگشت، اندازه‌گیری دوباره و اقدام پیشگیرانه. این روش شاید از یک Restart تصادفی کندتر به نظر برسد، اما نتیجه قابل اعتماد و تکرارپذیر می‌دهد.

• free -h نمای کلی می‌دهد.
• ps یا top مالک مصرف را مشخص می‌کند.
• vmstat نرخ swap-in و swap-out را نشان می‌دهد.