تقریبا هر کسی که با سرور لینوکس کار کرده، با دستور uptime یا نگاه کردن به گوشه بالای htop، با سه عدد مرموز روبه رو شده است:
load average: 2.45, 1.87, 1.32
خیلی ها سریع نتیجه می‌گیرند که «لود سرور بالاست» یا «CPU تحت فشار است». اما واقعیت این است که Load Average یکی از سوءتفاهم شده ترین متریک‌های لینوکس است. تفسیر اشتباه آن می‌تواند باعث تصمیم های نادرست شود. یا بی جهت سرور را scale کنید، یا مشکل واقعی را نادیده بگیرید.
در این مطلب با زبانی ساده اما دقیق بررسی می‌کنیم که Load Average دقیقا چه چیزی را نشان می‌دهد، چرا سه عدد دارد، چه زمانی نگران‌کننده است و چطور باید آن را درست تحلیل کنید.
Load Average دقیقا چیست؟
Load Average میانگین تعداد processها و threadهایی است که در حالت Runnable یا Uninterruptible Sleep قرار دارند.
Runnable: processهایی که آماده اجرا هستند و منتظر نوبت CPU می‌مانند.
Uninterruptible Sleep (معمولا حالت D): processهایی که منتظر I/O هستند (مثل خواندن از دیسک یا شبکه) و نمی‌توان آن‌ها را با سیگنال معمولی بیدار کرد.
پس Load Average فقط نشان دهنده استفاده از CPU نیست. بلکه ترکیبی از فشار روی CPU و فشار روی I/O را نشان می‌دهد.
معنی سه عدد
سه عددی که می‌بینید میانگین لود در بازه‌های زمانی مختلف هستند:
عدد اول: میانگین ۱ دقیقه اخیر
عدد دوم: میانگین ۵ دقیقه اخیر
عدد سوم: میانگین ۱۵ دقیقه اخیر
این ساختار به شما کمک می‌کند روند را ببینید:
اگر عدد ۱ دقیقه‌ای خیلی بالاتر از ۱۵ دقیقه‌ای باشد → فشار تازه و ناگهانی آمده.
اگر هر سه عدد بالا و نزدیک به هم باشند → فشار پایدار و طولانی‌مدت است.
اگر عدد ۱ دقیقه‌ای پایین آمده اما ۱۵ دقیقه‌ای هنوز بالاست → سیستم در حال بازیابی است.
چه زمانی Load Average نگران‌کننده است؟
قانون سرانگشتی قدیمی می‌گفت: «اگر Load Average از تعداد هسته‌های CPU بیشتر شود، مشکل دارید.»
این قانون ناقص است.
مثال:
سروری با ۸ هسته و Load Average برابر با ۱۲ ممکن است کاملا سالم باشد، اگر بخش زیادی از آن لود مربوط به I/O باشد و CPU بیکار مانده باشد.
در مقابل، سروری با ۴ هسته و Load Average برابر با ۳.۵ که تقریباً تمامش CPU-bound است، می‌تواند با latency بالا و کندی واقعی روبه رو باشد.
پس همیشه باید Load Average را همراه با متریک‌های دیگر ببینید:
درصد استفاده از CPU (%user, %system, %iowait)
تعداد processهای در حالت D
Latency دیسک و شبکه
Context switch و run queue length
اشتباهات رایج در تفسیر
۱. بالا بودن Load Average را مساوی با کمبود CPU دانستن:
خیلی وقت‌ها مشکل از دیسک کند، شبکه، یا lockهای دیتابیس است، نه کمبود قدرت پردازشی.
۲. نادیده گرفتن تفاوت بین ۱، ۵ و ۱۵ دقیقه:
یک spike کوتاه در عدد ۱ دقیقه‌ای معمولا جای نگرانی ندارد. اما اگر عدد ۱۵ دقیقه‌ای به طور مداوم بالا بماند، باید بررسی شود.
۳. مقایسه Load Average بین سرورهای مختلف بدون در نظر گرفتن تعداد هسته:
Load Average برابر با ۱۰ روی یک سرور ۳۲ هسته‌ای وضعیت خیلی بهتری نسبت به همان عدد روی یک سرور ۴ هسته‌ای دارد.
۴. ترس از هر عدد بالاتر از ۱:
روی سرورهای مدرن و multi-core، Load Average زیر تعداد هسته‌ها معمولا طبیعی است.
چطور مشکل را ریشه‌یابی کنیم؟
وقتی Load Average بالا می‌رود، این مسیر را پیشنهاد می‌کنیم:
با htop یا top ببینید CPU در حال انجام چه کاری است. آیا %iowait بالاست؟
دستور ps -eo state,pid,cmd | grep '^D' را اجرا کنید تا processهای منتظر I/O را پیدا کنید.
با iotop یا iostat -x وضعیت دیسک را بررسی کنید.
اگر مشکوک به شبکه هستید، sar -n DEV یا ابزارهای مشابه را چک کنید.
در نهایت به سراغ خود اپلیکیشن بروید: queryهای سنگین، N+1، lock contention یا connection pool نامناسب.
چه کارهایی معمولا کمک می‌کند؟
بهینه سازی queryها و اضافه کردن ایندکس مناسب
استفاده درست از connection pooling
جدا کردن workloadهای I/O-heavy از CPU-heavy
ارتقای دیسک به SSD یا NVMe در صورت بالا بودن iowait
تنظیم درست تعداد workerها در اپلیکیشن (مثلا در Gunicorn، Node.js cluster یا thread poolها)
در محیط‌های container، مطمئن شدن از اینکه limitهای CPU و I/O درست تعریف شده‌اند
جمع بندی
Load Average یک متریک مفید است، اما به تنهایی داستان کامل را تعریف نمی‌کند. ارزش واقعی آن وقتی مشخص می‌شود که آن را در کنار CPU utilization، iowait، run queue و رفتار اپلیکیشن ببینید.
به‌جای واکنش هیجانی به «لود بالاست»، از خود بپرسید:
این لود از چه جنسی است؟ (CPU یا I/O)
از چه زمانی شروع شده؟
آیا با افزایش latency یا خطا همراه بوده؟
پاسخ به این سؤال‌ها شما را از تصمیم‌های عجولانه نجات می‌دهد و کمک می‌کند مشکل واقعی را پیدا کنید.