یکی از اولین شاخص‌هایی که مدیران سرور هنگام کند شدن یک VPS بررسی می‌کنند، Load Average است. بالا رفتن Load Average معمولاً با کندی سایت، افزایش زمان پاسخ سرویس‌ها، مصرف بالای CPU یا مشکلات دیسک همراه می‌شود؛ اما یک نکته مهم وجود دارد:

Load Average بالا لزوماً به معنی مصرف بالای CPU نیست.

ممکن است CPU تقریباً بیکار باشد، اما پردازش‌های زیادی منتظر خواندن یا نوشتن اطلاعات روی دیسک باشند. از طرف دیگر، کمبود RAM و فعال شدن Swap نیز می‌تواند باعث افزایش زمان انتظار و در نتیجه بالا رفتن Load شود.

بنابراین برای پیدا کردن علت واقعی مشکل، نباید فقط به Load Average نگاه کرد. باید مشخص کنیم فشار اصلی روی CPU، RAM یا I/O قرار دارد.

Load Average چیست؟

Load Average میانگین تعداد taskهایی را نشان می‌دهد که در یک بازه زمانی مشخص در وضعیت قابل اجرا یا در انتظار منابع خاص سیستم قرار دارند.

در لینوکس معمولاً سه عدد در خروجی uptime یا top مشاهده می‌کنیم:

uptime

مثلاً:

10:25:31 up 15 days,  4:12,  2 users,  load average: 4.20, 3.10, 1.85

این سه عدد به‌ترتیب نشان‌دهنده Load Average در:

• ۱ دقیقه گذشته
• ۵ دقیقه گذشته
• ۱۵ دقیقه گذشته

هستند.

آیا Load Average برابر با CPU Usage است؟

خیر.

این یکی از رایج‌ترین اشتباهات در مدیریت لینوکس است.

Load Average بیشتر نشان می‌دهد که چه تعداد task در حال کار یا منتظر منابع سیستم هستند. بنابراین ممکن است Load Average بالا باشد، در حالی که CPU Usage پایین است.

برای مثال، اگر تعداد زیادی پردازش منتظر دیسک باشند، Load Average می‌تواند افزایش پیدا کند بدون اینکه CPU واقعاً درگیر اجرای محاسبات سنگین باشد.

Load Average مناسب چقدر است؟

برای تفسیر Load Average باید تعداد CPUهای سیستم را هم در نظر گرفت.

فرض کنید VPS شما یک CPU منطقی دارد:

1 vCPU
Load Average: 1.00

در چنین شرایطی تقریباً ظرفیت یک CPU به‌طور کامل درگیر است.

اما اگر VPS دارای 4 vCPU باشد:

4 vCPU
Load Average: 1.00

این مقدار لزوماً نشانه مشکل نیست.

به‌صورت ساده می‌توان گفت:

اما این جدول فقط یک راهنمای ابتدایی است. Load Average به‌تنهایی معیار کافی برای تشخیص مشکل نیست.

قدم اول: تعداد CPU را بررسی کنید

برای مشاهده تعداد CPUهای منطقی:

nproc

یا:

lscpu

مثلاً:

CPU(s):                4

یعنی سیستم 4 CPU منطقی در اختیار دارد.

در VPS باید توجه داشت که vCPU لزوماً به معنی یک هسته فیزیکی اختصاصی نیست. در محیط‌های مجازی‌سازی، میزان واقعی منابعی که در اختیار VPS قرار می‌گیرد به نوع سرویس و سیاست‌های hypervisor نیز بستگی دارد.

چگونه بفهمیم Load به خاطر CPU است؟

اولین ابزار مناسب برای بررسی وضعیت سیستم:

top

یا در صورت نصب بودن:

htop

در خروجی top معمولاً چیزی شبیه این می‌بینید:

%Cpu(s): 85.0 us, 10.0 sy, 0.0 ni, 5.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

مهم‌ترین بخش‌ها عبارت‌اند از:

• us — زمان مصرف‌شده توسط برنامه‌های user space
• sy — زمان مصرف‌شده در kernel
• id — زمان بیکار بودن CPU
• wa — زمان انتظار برای I/O
• st — زمان steal در محیط مجازی

اگر چیزی شبیه این ببینید:

80.0 us
15.0 sy
2.0 wa
3.0 id

احتمالاً CPU واقعاً تحت فشار است.

اما اگر ببینید:

10.0 us
5.0 sy
70.0 wa
15.0 id

مشکل احتمالاً CPU نیست؛ بلکه سیستم زمان زیادی را منتظر I/O می‌ماند.

نقش Steal Time در VPS

در VPS یک شاخص مهم دیگر نیز وجود دارد:

st

یا Steal Time.

این مقدار نشان می‌دهد CPU مجازی شما چه میزان از زمان خود را منتظر hypervisor یا ماشین‌های مجازی دیگر بوده است.

مثلاً:

%Cpu(s): 20.0 us, 5.0 sy, 0.0 id, 0.0 wa, 75.0 st

در این وضعیت ممکن است داخل VPS تصور کنید CPU بسیار شلوغ است، در حالی که بخش بزرگی از زمان CPU توسط محیط مجازی‌سازی از VPS گرفته شده است.

در چنین شرایطی بررسی وضعیت خود VPS کافی نیست و ممکن است لازم باشد موضوع را با ارائه‌دهنده VPS مطرح کنید.

تشخیص CPU با دستور mpstat

اگر ابزار sysstat نصب باشد، می‌توان از mpstat استفاده کرد:

mpstat -P ALL 1

این دستور وضعیت CPUها را در بازه‌های یک‌ثانیه‌ای نمایش می‌دهد.

برای نصب در Debian/Ubuntu:

sudo apt install sysstat

در سیستم‌های RHEL/CentOS/AlmaLinux/Rocky Linux معمولاً:

sudo dnf install sysstat

با mpstat می‌توان فهمید آیا همه CPUها درگیر هستند یا فقط یک CPU خاص.

تشخیص پردازش‌های مصرف‌کننده CPU

با top می‌توانید پردازش‌ها را بر اساس CPU مرتب کنید.

در top معمولاً با فشردن:

P

پردازش‌ها بر اساس مصرف CPU مرتب می‌شوند.

همچنین می‌توانید مستقیماً از:

ps aux --sort=-%cpu | head

استفاده کنید.

مثلاً:

USER       PID %CPU %MEM COMMAND
mysql     1245 82.4 12.5 mysqld
www-data  2311 35.1  3.2 php-fpm
root      3120 18.4  1.1 ...

در این حالت باید بررسی کنید کدام سرویس واقعاً CPU را مصرف می‌کند.

آیا RAM باعث Load Average بالا می‌شود؟

RAM با CPU تفاوت دارد، اما کمبود شدید RAM می‌تواند به شکل غیرمستقیم باعث افزایش Load و کندی سیستم شود.

برای مشاهده وضعیت RAM:

free -h

مثلاً:

               total        used        free      shared
Mem:            8.0Gi       7.2Gi       300Mi
Swap:           2.0Gi       1.8Gi       200Mi

در اینجا استفاده زیاد از Swap می‌تواند نشانه فشار حافظه باشد؛ البته پر بودن RAM به‌تنهایی الزاماً مشکل نیست، چون لینوکس از RAM آزاد برای cache نیز استفاده می‌کند.

به چه چیزی در خروجی free توجه کنیم؟

دستور:

free -h

در نسخه‌های جدید Linux مقدار مهمی به نام:

available

نمایش می‌دهد.

برای ارزیابی سریع وضعیت حافظه، available معمولاً از free معیار مفیدتری است.

مثلاً:

Mem:
total        8G
used         7G
free         300M
available    2.8G

در این شرایط، با وجود اینکه مقدار free کم است، سیستم هنوز مقدار قابل توجهی حافظه در اختیار دارد.

Swap چیست و چرا مهم است؟

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

Swap ممکن است روی یک پارتیشن یا فایل قرار داشته باشد.

برای مشاهده وضعیت Swap:

swapon --show

و:

free -h

اما یک نکته مهم وجود دارد:

استفاده شدن از Swap همیشه به معنی مشکل نیست.

مهم‌تر از مقدار Swap استفاده‌شده، میزان فعالیت مداوم Swap است.

برای بررسی آن می‌توان از:

vmstat 1

استفاده کرد.

در خروجی vmstat ستون‌های:

si
so

مهم هستند.

• si = مقدار swap in
• so = مقدار swap out

اگر این مقادیر به‌صورت مداوم بالا باشند، احتمال فشار حافظه بیشتر می‌شود.

تشخیص I/O؛ یکی از مهم‌ترین دلایل Load بالا

یکی از رایج‌ترین سناریوها این است:

Load Average: بالا
CPU Usage: پایین

در این حالت باید I/O را بررسی کنید.

I/O یعنی عملیات ورودی/خروجی، مانند:

• خواندن از دیسک
• نوشتن روی دیسک
• دسترسی به فایل‌ها
• فعالیت دیتابیس
• لاگ‌نویسی شدید
• عملیات روی storage شبکه‌ای

برای بررسی اولیه:

iostat -xz 1

اگر دستور موجود نیست، معمولاً باید بسته sysstat را نصب کنید.

مهم‌ترین شاخص در iostat چیست؟

در خروجی iostat شاخص‌های مختلفی وجود دارند. یکی از مهم‌ترین آن‌ها:

%util

است.

همچنین باید به:

await

توجه کنید.

await مدت انتظار برای تکمیل عملیات I/O را نشان می‌دهد.

اگر await به شکل قابل توجهی افزایش پیدا کند و هم‌زمان سیستم تحت بار باشد، باید وضعیت storage و نوع workload را بررسی کنید.

اما یک عدد ثابت و جهانی برای «خراب بودن» وجود ندارد؛ تفسیر آن به نوع دیسک، workload و latency مورد انتظار بستگی دارد.

بررسی I/O با pidstat

یکی از ابزارهای مفید برای پیدا کردن پردازش‌های I/O-intensive:

pidstat -d 1

این دستور اطلاعات I/O مربوط به پردازش‌ها را نمایش می‌دهد.

مثلاً ممکن است متوجه شوید:

mysqld

در حال خواندن یا نوشتن حجم زیادی از اطلاعات است.

یا یک process مربوط به backup، compression یا logging باعث فشار روی دیسک شده است.

استفاده از iotop

ابزار دیگری که برای مشاهده پردازش‌های فعال در I/O بسیار کاربردی است:

sudo iotop

در بعضی توزیع‌ها ممکن است لازم باشد آن را نصب کنید.

iotop کمک می‌کند بفهمید کدام process بیشترین فعالیت I/O را دارد.

برای مثال ممکن است علت مشکل یکی از موارد زیر باشد:

mysqld
rsync
tar
backup script
php-fpm
docker

Load بالا + CPU پایین؛ چه معنایی دارد؟

فرض کنید:

Load Average: 8.5
CPU idle: 60%
I/O wait: 35%

این وضعیت نشان می‌دهد که Load بالا احتمالاً ناشی از CPU نیست.

در چنین شرایطی باید موارد زیر را بررسی کنید:

1. وضعیت دیسک
2. latency storage
3. دیتابیس
4. backup
5. عملیات سنگین فایل
6. Docker یا containerها
7. NFS یا storage شبکه‌ای
8. Swap و memory pressure

Load بالا + CPU بالا

حالت دیگری:

Load Average: 6.5
CPU idle: 2%
I/O wait: 1%

اگر VPS مثلاً 2 vCPU داشته باشد، چنین وضعیتی می‌تواند نشان‌دهنده فشار شدید CPU باشد.

در این حالت باید به سراغ processهایی بروید که CPU را مصرف می‌کنند:

top

یا:

ps aux --sort=-%cpu | head -20

سپس مشخص کنید کدام سرویس عامل مصرف CPU است.

برای مثال:

• PHP-FPM
• MySQL/MariaDB
• Nginx
• Apache
• Node.js
• Java
• Python
• Docker
• cron job

ممکن است عامل اصلی باشند.

Load بالا + RAM کم + Swap فعال

سناریوی دیگری:

Load Average: 5.8
RAM: تقریباً پر
Swap: فعال
si/so: بالا
CPU: متوسط

در این حالت احتمال memory pressure وجود دارد.

راهکار ممکن است شامل موارد زیر باشد:

• پیدا کردن processهای پرمصرف
• کاهش مصرف حافظه
• اصلاح تنظیمات سرویس‌ها
• افزایش RAM
• بررسی memory leak
• بهینه‌سازی دیتابیس
• بررسی تعداد workerهای PHP-FPM یا سرویس مشابه

برای پیدا کردن processهای پرمصرف RAM:

ps aux --sort=-%mem | head -20

چگونه بفهمیم چه پردازشی باعث مشکل شده است؟

یک روش ساده این است که ابتدا:

top

را اجرا کنید.

سپس به سه بخش توجه کنید:

1. CPU

اگر process خاصی CPU زیادی مصرف می‌کند، آن را بررسی کنید.

2. Memory

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

3. وضعیت کلی CPU

به این مقادیر توجه کنید:

us
sy
wa
st
id

این چند مقدار می‌توانند مسیر عیب‌یابی را مشخص کنند.

دستورهای ضروری برای عیب‌یابی Load Average

یک مجموعه ساده و کاربردی از دستورات:

uptime

برای دیدن Load Average.

nproc

برای تعداد CPU.

top

برای مشاهده وضعیت کلی سیستم و processها.

free -h

برای بررسی RAM و Swap.

vmstat 1

برای بررسی CPU، memory و وضعیت swap.

iostat -xz 1

برای بررسی I/O و storage.

pidstat -d 1

برای پیدا کردن processهای فعال در I/O.

ps aux --sort=-%cpu | head -20

برای پیدا کردن مصرف‌کنندگان CPU.

ps aux --sort=-%mem | head -20

برای پیدا کردن مصرف‌کنندگان RAM.

یک روش عملی برای عیب‌یابی

فرض کنید کاربر گزارش می‌دهد:

VPS من کند شده و Load Average خیلی بالاست.

بهتر است بدون حدس زدن، مرحله‌به‌مرحله جلو بروید.

مرحله اول: Load را ببینید

uptime

مثلاً:

load average: 7.20, 6.80, 5.90

مرحله دوم: تعداد CPU را بررسی کنید

nproc

اگر خروجی:

2

باشد، Load برابر 7 نسبت به ظرفیت CPU عدد قابل توجهی است و نیاز به بررسی دارد.

مرحله سوم: CPU را بررسی کنید

top

اگر:

CPU idle = 1%

باشد، احتمال فشار CPU بالاست.

اما اگر:

CPU idle = 60%
I/O wait = 35%

باشد، باید I/O را بررسی کنید.

مرحله چهارم: RAM را بررسی کنید

free -h

اگر Swap به‌شدت فعال است، memory pressure را بررسی کنید.

مرحله پنجم: I/O را بررسی کنید

iostat -xz 1

سپس:

pidstat -d 1

را اجرا کنید تا مشخص شود چه processهایی بیشترین I/O را ایجاد می‌کنند.

یک چک‌لیست سریع

اشتباهات رایج هنگام بررسی Load Average

اشتباه اول: Load بالا یعنی CPU بالا

این تصور همیشه درست نیست.

Load می‌تواند به دلیل انتظار برای I/O نیز بالا برود.

اشتباه دوم: RAM استفاده‌شده زیاد یعنی RAM کم داریم

لینوکس از RAM برای cache استفاده می‌کند.

بنابراین باید available، Swap و رفتار سیستم را هم بررسی کنید.

اشتباه سوم: فقط Load Average را بررسی کنیم

Load فقط یک علامت است، نه تشخیص نهایی.

باید همراه آن CPU، RAM، Swap، I/O و processها را بررسی کرد.

اشتباه چهارم: بلافاصله VPS را ریبوت کنیم

Restart ممکن است موقتاً مشکل را برطرف کند، اما علت اصلی را مشخص نمی‌کند.

اگر مشکل به دلیل memory leak، query سنگین، backup، cron job یا storage bottleneck باشد، احتمال دارد دوباره برگردد.

یک سناریوی واقعی

فرض کنید VPS شما این مشخصات را دارد:

4 vCPU
8 GB RAM

و خروجی:

load average: 10.5, 9.8, 8.9

در نگاه اول Load بسیار بالا به نظر می‌رسد.

اما top نشان می‌دهد:

CPU idle: 55%
I/O wait: 35%

در اینجا افزایش Load احتمالاً ناشی از محاسبات CPU نیست.

سپس:

iostat -xz 1

نشان می‌دهد که latency دیسک افزایش یافته است.

با اجرای:

pidstat -d 1

مشخص می‌شود یک backup process در حال خواندن حجم زیادی از فایل‌هاست.

در این حالت افزایش Load Average بیشتر یک نشانه فشار I/O است تا نشانه کمبود CPU.

آیا افزایش Load Average همیشه بد است؟

خیر.

Load Average باید در context تفسیر شود.

برای مثال یک سرور پردازشی ممکن است عمداً workload سنگینی داشته باشد و Load بالایی تولید کند، بدون اینکه مشکلی وجود داشته باشد.

چیزی که اهمیت دارد این است که آیا:

• سرویس‌ها کند شده‌اند؟
• latency افزایش پیدا کرده؟
• CPU اشباع شده؟
• I/O به bottleneck تبدیل شده؟
• RAM تحت فشار است؟
• Swap به‌صورت مداوم فعال است؟
• processها در صف قرار گرفته‌اند؟

بنابراین بهتر است به جای دنبال کردن یک «عدد جادویی» برای Load Average، رفتار کلی سیستم را بررسی کنیم.

جمع‌بندی

Load Average یک شاخص مهم برای سلامت و فشار سیستم لینوکس است، اما به‌تنهایی نمی‌تواند علت مشکل را مشخص کند.

برای عیب‌یابی صحیح باید ابتدا Load را ببینیم و سپس مشخص کنیم فشار اصلی از کجا می‌آید:

Load Average
      │
      ├── CPU بالا؟
      │      └── top / mpstat / ps
      │
      ├── I/O Wait بالا؟
      │      └── iostat / pidstat / iotop
      │
      ├── RAM تحت فشار؟
      │      └── free / vmstat
      │
      └── Steal Time بالا؟
             └── بررسی وضعیت VPS / Hypervisor

بهترین روش این است که Load Average را به‌عنوان نقطه شروع عیب‌یابی ببینیم، نه نتیجه نهایی.

اگر Load بالا است، ابتدا تعداد vCPU را بررسی کنید؛ سپس CPU، I/O، RAM و Swap را به‌صورت هم‌زمان بررسی کنید. با این روش می‌توان به جای حدس زدن، علت واقعی کندی VPS را پیدا کرد.