بررسی مصرف CPU، RAM و دیسک لینوکس؛ پیدا کردن علت کندی سرور

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

۱. نمای کلی سرور

date -Is
uptime
nproc
free -h
df -h
df -i

uptime میانگین بار را نشان می‌دهد، نه درصد مصرف CPU. آن را با تعداد پردازنده‌های قابل استفاده و وضعیت انتظار I/O تفسیر کنید. df -h ظرفیت فایل‌سیستم و df -i مصرف inode را نشان می‌دهد؛ ممکن است با وجود فضای خالی، تعداد زیاد فایل‌های کوچک inodeها را پر کرده باشد.

۲. پردازش پرمصرف را پیدا کنید

top
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 15
ps -eo pid,comm,%cpu,%mem --sort=-%mem | head -n 15

در top با q خارج شوید. PID و نام پردازش را ثبت و مالک سرویس را مشخص کنید. درصد CPU ابزارها همیشه بر یک مبنای یکسان نیست؛ پردازش چندریسمانی ممکن است بیش از 100 درصد نشان داده شود. یک پردازش پایگاه دادهٔ فعال را صرفاً به دلیل مصرف بالا kill نکنید؛ ممکن است در حال انجام کار ضروری باشد.

۳. کمبود RAM را از کش تشخیص دهید

free -h
vmstat 1 5

در free ستون available برای تخمین حافظهٔ قابل استفاده مهم‌تر از نگاه‌کردن صرف به free است. لینوکس از حافظه برای کش هم استفاده می‌کند. در vmstat، فعالیت مداوم si و so همراه کندی می‌تواند نشانهٔ جابه‌جایی حافظه با Swap باشد؛ اولین سطر نمای متفاوتی از سطرهای نمونه‌برداری بعدی دارد. Swap جایگزین RAM کافی نیست.

برای بررسی رخدادهای کمبود حافظه، لاگ کرنل را بخوانید و دنبال پیام‌های OOM بگردید:

sudo journalctl -k --since "1 hour ago" --no-pager

۴. پوشه‌ها و فایل‌های حجیم

ابتدا همان فایل‌سیستم پرشده را هدف بگیرید. مثال زیر /var را بررسی می‌کند؛ اجرای du روی حجم‌های بزرگ ممکن است خودش I/O ایجاد کند:

sudo du -xhd1 /var | sort -h
sudo find /var/log -xdev -type f -size +100M -printf "%s %p\n"
sudo journalctl --disk-usage

گزینهٔ -x از عبور به فایل‌سیستم دیگر جلوگیری می‌کند. اندازهٔ find برحسب بایت است. قبل از حذف، معلوم کنید فایل متعلق به چه برنامه‌ای است و سیاست نگهداری چیست. فایل دیتابیس، فایل فعال برنامه و پوشه‌های Docker را دستی پاک نکنید. برای لاگ‌ها، تنظیم چرخش و مدت نگهداری راه‌حل اصولی‌تری است.

۵. چرا df و du عدد یکسان ندارند؟

دلایل متعددی وجود دارد؛ از فایل‌های حذف‌شده‌ای که هنوز توسط پردازش باز هستند تا متادیتا و فضای رزروشده. اگر lsof نصب است، می‌توانید فایل‌های باز حذف‌شده را بررسی کنید:

sudo lsof +L1

این خروجی مجوز Restart فوری سرویس نیست. ابتدا پردازش و اثر توقف آن را مشخص کنید؛ سپس در بازهٔ مناسب اقدام کنید. حذف دوبارهٔ فایل یا ریبوت بدون بررسی، علت اصلی رشد را حل نمی‌کند.

۶. آیا گلوگاه دیسک است؟

اگر ابزار iostat از بستهٔ sysstat در دسترس است:

iostat -xz 1 5

تأخیر و صف را در کنار بار برنامه بررسی کنید. یک درصد utilization بالا برای همهٔ انواع ذخیره‌سازی یک تفسیر یکسان ندارد. روی VPS، رفتار میزبان و محدودیت‌های پلن هم مؤثرند. بدون شواهد، نتیجه نگیرید که حتماً دیسک خراب است یا باید پلن عوض شود.

۷. اقدام بعدی بر اساس شواهد

برای CPU بالا، درخواست‌ها و پردازش‌ها؛ برای RAM کم، مصرف برنامه و OOM؛ برای دیسک پر، منشأ رشد فایل؛ و برای تأخیر شبکه، راهنمای شبکه را بررسی کنید. پیش از پاک‌سازی یا تغییر مهم، بکاپ مستقل داشته باشید. اگر بعد از اصلاح برنامه هنوز ظرفیت کافی نیست، منابع لازم را با اندازه‌گیری انتخاب کنید.

منابع و ادامهٔ یادگیری

مبنای مثال‌های سرور، اوبونتو ۲۴٫۰۴ LTS است؛ نام سرویس‌ها و روش نصب در توزیع‌های دیگر ممکن است متفاوت باشد. تصویر مقاله مفهومی است. این دستورها هنگام تهیهٔ مقاله روی سرویس واقعی مشتری اجرا نشده‌اند.

منابع رسمی: راهنمای free، راهنمای top

برای انتخاب زیرساخت، سرورهای لینوکس و چک‌لیست خرید VPS را ببینید. آموزش‌های مکمل در مرکز آموزش پرشین کلود در دسترس‌اند.