لود بالای سرور مجازی؛ تشخیص CPU، iowait، Swap و OOM پیش از ارتقا

لود بالای سرور مجازی همیشه به معنی کمبود CPU یا نیاز فوری به ارتقای پلن نیست. عدد Load Average فقط یک هشدار اولیه است؛ این عدد می‌تواند به‌دلیل صف پردازش‌های منتظر CPU، انتظار برای دیسک، فشار حافظه، Swap سنگین، یک پردازه معیوب، بکاپ هم‌زمان یا حتی محدودیت لایه مجازی‌سازی بالا برود. تصمیم درست زمانی گرفته می‌شود که هم‌زمان با لود، وضعیت CPU، ستون iowait، حافظه Available، نرخ Swap، رخدادهای OOM، صف دیسک و الگوی زمانی مشکل را بررسی کنید.

در این راهنما یاد می‌گیرید چگونه بدون تغییر عجولانه و با ابزارهای خواندنی لینوکس، منشأ کندی را مرحله‌به‌مرحله پیدا کنید. هدف فقط پایین‌آوردن یک عدد نیست؛ باید بفهمیم کدام منبع جلوی پیشرفت کار واقعی را گرفته است، آیا مشکل موقتی یا پایدار است و چه زمانی بهینه‌سازی کافی است یا باید سرور مجازی متناسب‌تری انتخاب شود. هیچ عدد ثابت و جهانی برای «لود خوب» وجود ندارد و تفسیر باید براساس تعداد هسته، نوع بار و خط مبنای همان سرویس انجام شود.

فهرست مطالب

• پاسخ سریع: لود بالا دقیقاً یعنی چه؟
• تفسیر Load Average در سرور مجازی
• ساخت خط مبنا پیش از عیب‌یابی
• تشخیص فشار واقعی CPU و Run Queue
• تشخیص iowait و گلوگاه دیسک
• بررسی RAM، Swap و OOM
• اثر Steal Time و لایه مجازی‌سازی
• زنجیره عیب‌یابی مرحله‌به‌مرحله
• سناریوهای کاربردی
• بهینه‌سازی یا ارتقای سرور مجازی؟
• چک‌لیست انتخاب و خرید
• سؤالات متداول

پاسخ سریع: لود بالای سرور مجازی دقیقاً چه می‌گوید؟

Load Average میانگینی از تعداد کارهایی است که در حال اجرا هستند، منتظر CPU مانده‌اند یا در لینوکس در حالت انتظار غیرقابل‌قطع—اغلب برای I/O—قرار دارند. سه عددی که در خروجی uptime یا بالای top می‌بینید، بازه‌های یک، پنج و پانزده دقیقه را نشان می‌دهند. این اعداد درصد نیستند و به‌صورت خودکار براساس تعداد هسته نرمال نمی‌شوند. بنابراین Load برابر ۴ روی ماشین دو هسته‌ای با همان عدد روی ماشین هشت هسته‌ای تفسیر یکسانی ندارد.

آنچه می‌بینید	برداشت اولیه	کنترل بعدی
Load بالا و CPU user/system بالا	احتمال صف پردازش CPU	پردازه‌ها، تعداد هسته، run queue و زمان CPU
Load بالا و CPU عمدتاً idle	احتمال انتظار I/O یا Task در حالت D	iowait، vmstat، iostat، لاگ دیسک
RAM ظاهراً پر ولی Available مناسب	ممکن است بخش زیادی Cache قابل‌بازیابی باشد	MemAvailable، Swap in/out و Memory Pressure
Swap رو به رشد و پاسخ‌گویی ناپایدار	فشار حافظه یا Working Set بزرگ‌تر از RAM	si/so، PSI، پردازه‌های پرمصرف و OOM
CPU داخل مهمان پایین ولی steal بالا	رقابت برای CPU در میزبان مجازی‌سازی	روند st، زمان رخداد و گزارش مستند به پشتیبانی

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

Load Average را چگونه درست تفسیر کنیم؟

خروجی زیر را تصور کنید:

uptime
12:40:18 up 18 days,  3:21,  2 users,  load average: 7.80, 5.40, 2.10

روند یک‌دقیقه‌ای از پنج و پانزده دقیقه بیشتر است؛ پس فشار فعلی رو به افزایش است. اما هنوز نمی‌دانیم این فشار از CPU آمده یا I/O. برعکس، اگر عدد یک‌دقیقه‌ای کمتر از پانزده‌دقیقه‌ای باشد، ممکن است موج قبلی در حال فروکش‌کردن باشد. تعداد هسته را با nproc یا lscpu بررسی کنید، ولی نسبت Load به هسته را حکم قطعی ندانید؛ پردازه‌های منتظر دیسک هم می‌توانند Load را افزایش دهند.

سه بازه زمانی چه کمکی می‌کنند؟

1. یک دقیقه: تغییر تازه، Burst یا شروع ناگهانی یک Job را نشان می‌دهد.
2. پنج دقیقه: مشخص می‌کند فشار فقط یک جهش کوتاه بوده یا ادامه دارد.
3. پانزده دقیقه: نمای آرام‌تری از پایداری مشکل می‌دهد و برای مقایسه با روال عادی مفید است.

چرا قانون «Load بیشتر از تعداد هسته یعنی بحران» کافی نیست؟

این قانون فقط یک نقطه شروع است. اگر بار CPU-bound و پایدار باشد، تشکیل صف بالاتر از ظرفیت پردازنده می‌تواند زمان پاسخ را زیاد کند. ولی Load بالا با CPU بیکار ممکن است از انتظار دیسک، فایل‌سیستم شبکه‌ای یا Taskهای حالت D بیاید. همچنین یک کار Batch می‌تواند Load بالا بسازد ولی کاربران را آزار ندهد، درحالی‌که یک Query کوتاه اما قفل‌کننده با Load پایین تجربه کاربری را خراب کند. پس شاخص‌های سطح سرویس—زمان پاسخ، خطا و توان عملیاتی—را کنار شاخص‌های سیستم ببینید.

پیش از عیب‌یابی، خط مبنای سرور را بسازید

بدون خط مبنا، یک Snapshot لحظه‌ای ممکن است گمراه‌کننده باشد. ابتدا مشخص کنید سرور در ساعات عادی چه رفتاری دارد: Load معمول، مصرف CPU، حافظه Available، Swap فعال، زمان پاسخ سرویس، نرخ درخواست و عملیات دوره‌ای. سپس همان مقادیر را در ساعت کندی مقایسه کنید. اگر فقط بعد از نیمه‌شب و هم‌زمان با بکاپ یا فشرده‌سازی لود بالا می‌رود، راه‌حل با کندی دائمی در ساعات فروش متفاوت است.

حداقل اطلاعاتی که باید همراه Timestamp ثبت شوند

• ساعت دقیق شروع و پایان کندی با منطقه زمانی مشخص؛
• Load یک، پنج و پانزده دقیقه و تعداد vCPU؛
• درصدهای user، system، iowait، steal و idle؛
• حافظه total، available و Swap به‌همراه نرخ si/so؛
• پردازه‌های بالای فهرست CPU و حافظه؛
• زمان پاسخ یا خطای سرویس واقعی؛
• Jobهای هم‌زمان مانند بکاپ، Cron، گزارش‌گیری یا Import.

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

تشخیص فشار واقعی CPU و Run Queue

وقتی Load بالا است، اولین سؤال این نیست که «CPU چند درصد شده؟»؛ باید بدانیم زمان پردازنده در کدام حالت مصرف می‌شود و چه تعداد پردازه برای اجرا منتظرند. top یا htop نمای زنده می‌دهد و vmstat برای نمونه‌برداری کوتاه مفید است. در vmstat ستون r تعداد پردازه‌های قابل اجرا را نشان می‌دهد و ستون‌های us و sy زمان User و Kernel را جدا می‌کنند.

nproc
uptime
vmstat 2 10
ps -eo pid,ppid,comm,%cpu,%mem,stat --sort=-%cpu | head -20

گزارش اول vmstat معمولاً میانگین از زمان بوت است؛ برای رخداد فعلی، نمونه‌های بعدی را تحلیل کنید. اگر r به‌طور پایدار از ظرفیت پردازش جلو می‌زند و هم‌زمان user یا system بالا است، صف CPU محتمل می‌شود. یک جهش دوثانیه‌ای به‌تنهایی دلیل ارتقا نیست؛ مشکل باید با کندی سرویس و تکرار در چند نمونه هم‌زمان باشد.

تفاوت مصرف user و system

بالابودن us معمولاً به اجرای کد برنامه، PHP، Node.js، Python، فشرده‌سازی یا Queryهای محاسباتی اشاره می‌کند. بالابودن sy یعنی سهم بیشتری از زمان در Kernel مصرف شده و می‌تواند با شبکه، I/O، تعداد زیاد فراخوانی سیستمی، مدیریت فایل یا Context Switch مرتبط باشد. هیچ‌کدام به‌تنهایی بد نیستند؛ مهم این است که آیا ظرفیت برای پاسخ به درخواست‌های جدید باقی مانده و کدام پردازه این الگو را ساخته است.

وقتی یک پردازه در صدر CPU است چه کنیم؟

نام پردازه فقط نقطه شروع است. پیش از Restart یا Kill، مالک، Parent، زمان اجرا، فرمان کامل، فایل لاگ و ارتباط آن با سرویس را ثبت کنید. یک پردازه دیتابیس پرمصرف ممکن است قربانی Query بد برنامه باشد، نه علت مستقل. یک Worker وب هم ممکن است به‌دلیل تماس کند با API خارجی زمان CPU کمی مصرف کند اما Workerها را مشغول نگه دارد. تصمیم باید از سطح Process به درخواست، Query یا Job برسد.

اگر مصرف پردازه کوتاه و ناپایدار است

از چند نمونه پیوسته استفاده کنید و فقط به یک مرتب‌سازی top تکیه نکنید. PID ممکن است عوض شود یا چند Worker بار را تقسیم کنند. الگوی سرویس، نام فرمان و گروه پردازه‌ها مهم‌تر از دنبال‌کردن یک PID منفرد است.

حداقل شواهد پیش از توقف پردازه

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

Context Switch و پردازه‌های بیش از حد

گاهی CPU کاملاً در کد مفید مصرف نمی‌شود؛ تعداد زیاد Thread یا Process، زمان را صرف جابه‌جایی Context می‌کند. ستون cs در vmstat را با خط مبنای خود مقایسه کنید. افزایش cs بدون رشد متناسب Throughput می‌تواند نشانه تنظیم نامناسب تعداد Worker، Loop معیوب یا رقابت قفل باشد. افزایش Worker همیشه ظرفیت را بیشتر نمی‌کند؛ اگر CPU، RAM یا دیتابیس محدود باشد، Worker بیشتر فقط صف را به لایه دیگری منتقل می‌کند.

iowait چیست و چگونه گلوگاه دیسک را تشخیص دهیم؟

iowait بخشی از زمان CPU است که سیستم کار قابل اجرای دیگری ندارد و دست‌کم یک عملیات I/O در انتظار است. بالابودن wa می‌تواند سرنخی از فشار ذخیره‌سازی باشد، اما یک درصد منفرد کافی نیست. باید هم‌زمان صف پردازه‌های Blocked، نرخ خواندن و نوشتن، Latency درخواست‌ها و وضعیت سرویس را ببینید. در ماشین مجازی نیز لایه میزبان و ذخیره‌سازی اشتراکی می‌تواند روی نتیجه اثر بگذارد.

vmstat 2 10
iostat -xz 2 10
ps -eo pid,comm,state,wchan:32 --sort=state | head -30
dmesg --level=err,warn | tail -50

اجرای iostat به بسته sysstat وابسته است و ممکن است روی همه توزیع‌ها نصب نباشد. بدون تغییر سیستم، ابتدا موجودبودن دستور را بررسی کنید. در گزارش Extended، شاخص‌هایی مانند await و aqu-sz به زمان انتظار و طول صف کمک می‌کنند. %util برای دیسک‌های سریال قدیمی مفید است، اما روی NVMe و آرایه‌های موازی به‌تنهایی سقف واقعی کارایی را نشان نمی‌دهد؛ Latency و Throughput را نیز در نظر بگیرید.

علت‌های رایج افزایش انتظار دیسک

• بکاپ یا فشرده‌سازی بزرگ هم‌زمان با ترافیک اصلی؛
• Queryهای دیتابیس بدون Index مناسب یا جدول‌های بزرگ؛
• ثبت لاگ بیش از حد یا Loop خطا؛
• صف Import، Export، پردازش تصویر یا استخراج آرشیو؛
• فایل‌سیستم نزدیک به پرشدن یا کمبود inode؛
• فشار Swap که خواندن و نوشتن دیسک را تشدید می‌کند؛
• خطای ذخیره‌سازی یا مشکل زیرساختی که در لاگ Kernel دیده می‌شود.

چرا حذف Cache یا Restart کورکورانه مشکل را پنهان می‌کند؟

Restart ممکن است صف را موقتاً خالی کند و Cache را تغییر دهد، اما شواهد اصلی از بین می‌روند. اگر مشکل با اجرای مجدد Job برگردد، دوباره در نقطه اول هستید. ابتدا Snapshot خواندنی از Load، Process، Memory، I/O و Log بگیرید؛ سپس تغییر را یکی‌یکی اجرا و نتیجه را با همان سناریو اندازه‌گیری کنید.

نشانه	تفسیر محتمل	آزمایش کم‌ریسک
wa بالا و b در vmstat رو به رشد	پردازه‌ها منتظر I/O هستند	iostat و تطبیق با Jobهای زمان‌بندی‌شده
await بالا برای یک Device	صف یا تأخیر همان مسیر ذخیره‌سازی	بررسی نوع عملیات و پردازه مولد I/O
دیسک تقریباً پر	ریسک خطا و افت عملکرد برخی سرویس‌ها	df، du و پاک‌سازی کنترل‌شده پس از Backup
I/O همراه با si/so بالا	فشار حافظه، دیسک را نیز درگیر کرده است	تحلیل Working Set و پردازه‌های حافظه‌بر
خطای I/O در Kernel Log	احتمال مشکل جدی‌تر ذخیره‌سازی	حفظ داده، ثبت شواهد و تماس فوری با پشتیبانی

RAM پر، Swap و OOM را چگونه تحلیل کنیم؟

در لینوکس، «RAM خالی کم» لزوماً بد نیست. Kernel از حافظه برای Page Cache و Buffer استفاده می‌کند و بخشی از آن هنگام نیاز قابل‌بازیابی است. ستون available در free تخمینی از حافظه قابل استفاده برای برنامه‌های جدید بدون Swap را ارائه می‌دهد و برای تصمیم‌گیری از نگاه‌کردن صرف به ستون free مفیدتر است.

free -h
vmstat 2 10
ps -eo pid,comm,%mem,rss,vsz --sort=-rss | head -20
cat /proc/pressure/memory
journalctl -k --since "2 hours ago" | grep -Ei 'oom|out of memory|killed process'

فرمان آخر نیازمند دسترسی مناسب به Journal است و مسیر لاگ بسته به توزیع فرق می‌کند. دنبال سه الگو باشید: Available که پیوسته افت می‌کند، Swap-in/Swap-out فعال و مداوم، و رخداد OOM که در آن Kernel برای حفظ سیستم یک پردازه را متوقف می‌کند. وجود مقداری Swap مصرف‌شده به‌تنهایی بحران نیست؛ ممکن است صفحه‌های سرد قدیمی در Swap مانده باشند. مشکل زمانی جدی‌تر است که si و so در زمان کندی فعال باشند و Latency سرویس بالا برود.

Memory Leak یا رشد طبیعی Cache؟

Cache معمولاً با فشار حافظه قابل‌بازیابی است، اما Memory Leak الگوی رشد مداوم یک پردازه را نشان می‌دهد. RSS پردازه را در طول زمان ثبت کنید و آن را با ترافیک و کار انجام‌شده بسنجید. اگر پس از پایان بار، مصرف به خط مبنا برنمی‌گردد و هر چرخه بالاتر می‌رود، بررسی Leak منطقی است. VSZ بزرگ الزاماً به معنی مصرف فیزیکی همان مقدار RAM نیست؛ RSS و ابزار اختصاصی Runtime را نیز ببینید.

OOM Killer چه زمانی وارد عمل می‌شود؟

وقتی تخصیص حافظه با بازیابی و سیاست‌های موجود تأمین نشود، Kernel ممکن است برای بقای سیستم یک Task را قربانی کند. نتیجه می‌تواند Restart شدن دیتابیس، Worker وب یا سرویس دیگری باشد. فقط سرویس کشته‌شده را دوباره اجرا نکنید؛ زمان رخداد، مصرف حافظه، OOM Score، محدودیت cgroup و علت رشد Working Set را بررسی کنید. در محیط کانتینری ممکن است OOM در محدوده همان cgroup رخ دهد، حتی اگر کل ماشین هنوز حافظه ظاهراً آزاد داشته باشد.

آیا افزودن Swap مشکل کمبود RAM را حل می‌کند؟

Swap می‌تواند حاشیه امن و زمان واکنش ایجاد کند، اما جای RAM برای Working Set فعال نیست. اگر برنامه دائماً میان RAM و Swap جابه‌جا شود، Thrashing رخ می‌دهد و تأخیر شدید می‌شود. اندازه و سیاست Swap باید متناسب با نوع سرویس، دیسک، Crash Dump و محدودیت‌های زیرساخت باشد. تغییر Swappiness یا ساخت Swap بدون شناخت بار، نسخه عمومی و مطمئنی نیست.

Steal Time و کیفیت لایه مجازی‌سازی

در ماشین مجازی، ستون st نشان می‌دهد چه بخشی از زمانی که vCPU آماده اجرا بوده، Hypervisor CPU فیزیکی را به کار دیگری اختصاص داده است. افزایش کوتاه و پراکنده ممکن است محسوس نباشد، اما Steal پایدار و هم‌زمان با کندی می‌تواند نشانه رقابت در میزبان باشد. مقاله CPU Steal و کیفیت واقعی سرور مجازی این موضوع را عمیق‌تر بررسی می‌کند.

برای گزارش مؤثر، اسکرین‌شات یک لحظه کافی نیست. بازه زمانی، چند نمونه پیوسته، تعداد vCPU، Load، user/system/iowait/steal و زمان پاسخ سرویس را ثبت کنید. همچنین مطمئن شوید محدودیت داخل ماشین—مانند پردازه CPU-bound یا Worker بیش از حد—عامل اصلی نیست. این تفکیک کمک می‌کند پشتیبانی بتواند رخداد را در میزبان همان بازه بررسی کند.

زنجیره عیب‌یابی لود بالای سرور مجازی

مرحله ۱: مشکل کاربر را قابل‌اندازه‌گیری کنید

به‌جای جمله «سرور کند است»، یک معیار مشخص بنویسید: زمان پاسخ صفحه از ۳۰۰ میلی‌ثانیه به چهار ثانیه رسیده، SSH با تأخیر فرمان می‌گیرد، Query خاص Timeout می‌شود یا پردازش صف عقب افتاده است. بدون معیار، ممکن است Load را پایین بیاورید ولی تجربه کاربر تغییر نکند.

مرحله ۲: ساعت و هم‌زمانی را ثبت کنید

زمان دقیق را با Cron، بکاپ، Log Rotation، Import، گزارش‌گیری، اسکن امنیتی و کمپین ترافیکی تطبیق دهید. بسیاری از مشکلات ظرفیت، نتیجه هم‌زمان‌شدن کارهای سالم هستند. جابه‌جایی زمان Job کم‌اولویت گاهی از خرید منابع بیشتر مؤثرتر است.

مرحله ۳: چهار شاخه CPU، I/O، Memory و Virtualization را جدا کنید

شاخه	شاخص‌های اصلی	پرسش تصمیم
CPU	r، us، sy، پردازه‌های بالای CPU	آیا کار واقعی بیش از ظرفیت پردازنده صف ساخته است؟
I/O	b، wa، await، aqu-sz، خطاهای Kernel	آیا Taskها برای ذخیره‌سازی یا مسیر I/O متوقف‌اند؟
Memory	available، si/so، RSS، PSI و OOM	آیا Working Set در RAM جا می‌شود یا سیستم در Reclaim است؟
Virtualization	st و تکرار زمانی	آیا vCPU آماده اجراست ولی زمان میزبان دریافت نمی‌کند؟
Service	Latency، Error، Throughput و Queue	کدام شاخص سیستم واقعاً با افت سرویس هم‌بسته است؟

مرحله ۴: عامل تولید بار را تا سطح درخواست پیدا کنید

پس از تعیین شاخه، Process را به علت کاربردی وصل کنید: کدام URL، Query، Job، Container، کاربر یا فایل؟ ابزارهای برنامه مانند Slow Query Log، APM، Access Log، Queue Dashboard یا Profiler می‌توانند حلقه آخر را نشان دهند. اگر فقط می‌دانیم MySQL یا PHP پرمصرف است، هنوز تشخیص کامل نشده است.

مرحله ۵: یک تغییر، یک آزمون، یک نتیجه

تغییر هم‌زمان Worker، Cache، دیتابیس و پلن، علت موفقیت یا شکست را نامعلوم می‌کند. ابتدا Backup و راه بازگشت داشته باشید؛ یک تغییر کم‌ریسک انجام دهید؛ همان بار را تکرار کنید و معیارها را با خط مبنا مقایسه کنید. اگر اثر معنادار نبود، تغییر را برگردانید یا مستند کنید و به فرضیه بعدی بروید.

مثال‌های کاربردی از لود بالا

سناریو اول: فروشگاه هنگام کمپین کند می‌شود

در ساعت کمپین، Load و user CPU بالا می‌روند، Run Queue رشد می‌کند و زمان پاسخ صفحات پویا زیاد می‌شود؛ اما iowait و Swap آرام‌اند. بررسی Access Log نشان می‌دهد درخواست‌های جست‌وجو و فیلتر بدون Cache سهم اصلی را دارند. اقدام منطقی می‌تواند بهینه‌سازی Query، Cache نتایج قابل‌کش، محدودسازی درخواست پرهزینه و سپس Load Test باشد. اگر بار سالم پس از بهینه‌سازی همچنان CPU را اشباع کند، vCPU بیشتر تصمیم قابل دفاعی است.

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

Load بالا است، CPU user پایین و iowait و صف دیسک رشد می‌کنند. زمان رخداد با بکاپ فشرده و Dump دیتابیس تطابق دارد. در این حالت افزایش CPU احتمالاً کمکی نمی‌کند. جابه‌جایی زمان بکاپ، محدودکردن اولویت I/O در صورت پشتیبانی، تقسیم کار، نگهداری خارج از مسیر اصلی و آزمون بازیابی می‌تواند راه‌حل مؤثرتری باشد. قبل از هر تغییر، سیاست بکاپ و الزامات بازیابی حفظ شود.

سناریو سوم: RAM پر است اما سرویس هنوز سریع است

ستون free کوچک است، ولی available مناسب، Swap-in/out صفر و Memory Pressure ناچیز است. بخش بزرگی از حافظه Page Cache است. پاک‌کردن Cache فقط برای زیباترشدن عدد free می‌تواند کارایی را موقتاً بدتر کند. تا وقتی Latency، Reclaim و OOM نشانه مشکل نیستند، استفاده مفید از RAM یک رفتار طبیعی محسوب می‌شود.

سناریو چهارم: سرویس هر چند ساعت بدون خطای روشن Restart می‌شود

بررسی Journal و Kernel Log رخداد OOM را نشان می‌دهد. یک Worker در هر چرخه حافظه بیشتری می‌گیرد و RSS پس از پایان Job پایین نمی‌آید. افزایش RAM ممکن است فاصله رخداد را بیشتر کند ولی Leak را درمان نمی‌کند. باید نسخه و الگوی کد، محدودیت Worker، اندازه Batch و مسیر آزادسازی حافظه بررسی شود؛ هم‌زمان حاشیه امن برای جلوگیری از قطعی تا رفع ریشه‌ای در نظر گرفته شود.

سناریو پنجم: CPU برنامه پایین است اما پاسخ‌گویی نوسان دارد

در زمان کندی، steal افزایش پیدا می‌کند و داخل مهمان پردازه سنگینی دیده نمی‌شود. چند نمونه مستند با Timestamp جمع‌آوری و به پشتیبانی ارائه می‌شود. این سناریو با CPU-bound داخل ماشین فرق دارد و خرید vCPU بیشتر روی همان شرایط میزبان لزوماً راه‌حل نیست. کیفیت و سیاست تخصیص زیرساخت را نیز باید ارزیابی کرد.

اشتباه‌های رایج هنگام رفع لود بالا

1. خرید فوری منابع بیشتر: بدون تشخیص، ممکن است گلوگاه I/O، Query یا Leak باقی بماند.
2. کشتن پردازه پرمصرف: شواهد از بین می‌رود و تراکنش یا Job ضروری ناقص می‌شود.
3. خالی‌کردن Cache حافظه: عدد free بهتر دیده می‌شود ولی داده دوباره باید از دیسک خوانده شود.
4. تمرکز روی یک Snapshot: علت‌های متناوب فقط با روند و هم‌بستگی زمانی دیده می‌شوند.
5. نادیده‌گرفتن سرویس واقعی: Load بالا بدون افت SLO ممکن است اولویت کمتری از خطای کاربر با Load متوسط داشته باشد.
6. اعتماد به یک درصد جهانی: نوع دیسک، موازی‌سازی، تعداد هسته و معماری برنامه تفاوت ایجاد می‌کند.
7. تغییر چند تنظیم هم‌زمان: نتیجه قابل انتساب و قابل بازگشت نیست.

چه زمانی بهینه‌سازی کافی است و چه زمانی ارتقا لازم می‌شود؟

ارتقا زمانی منطقی است که بار سالم و ضروری، پس از رفع خطاهای واضح و تنظیم درست، به‌طور تکرارشونده ظرفیت را پر کند. برای مثال، Queryها Index مناسب دارند، Cache در نقاط درست فعال است، Jobها هم‌زمانی نامناسب ندارند، Leak مشاهده نمی‌شود و بااین‌حال در ساعات واقعی کسب‌وکار Run Queue، Latency و Error هم‌زمان رشد می‌کنند. در این حالت منابع بیشتر برای رشد واقعی مصرف می‌شوند.

وضعیت	اقدام اول	ارتقا چه زمانی؟
یک Query یا Job معیوب	رفع Query، Index یا زمان‌بندی	اگر بار سالم بعد از اصلاح هنوز ظرفیت می‌خواهد
CPU پایدار و صف درخواست سالم	پروفایل و کاهش کار هر درخواست	اگر Throughput موردنیاز از ظرفیت فعلی بیشتر است
iowait ناشی از بکاپ هم‌زمان	زمان‌بندی و طراحی I/O	اگر I/O ضروری و هم‌زمان قابل کاهش نیست
Memory Leak	رفع Leak و محدودکردن Batch	برای حاشیه امن، نه جایگزین رفع ریشه‌ای
Working Set سالم بزرگ‌تر از RAM	بررسی Cache و الگوی داده	وقتی Reclaim و Swap روی Latency اثر پایدار دارد
Steal Time پایدار	مستندسازی و بررسی زیرساخت	پس از تأیید کیفیت مقصد، نه صرفاً افزایش تعداد vCPU

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

چک‌لیست انتخاب سرور مجازی برای بار پایدار

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

• بار اصلی CPU-bound، Memory-bound، I/O-bound یا ترکیبی است؟
• میانگین کافی است یا Peak کوتاه و حساس دارید؟
• چه تعداد پردازش هم‌زمان و چه زمان پاسخ هدفی لازم است؟
• Working Set حافظه در ساعت اوج چقدر است و آیا Swap فعال می‌شود؟
• دیتابیس، لاگ، بکاپ و فایل‌های موقت چه الگوی I/O دارند؟
• رشد سه تا شش ماه آینده و حاشیه امن چقدر است؟
• برای مانیتورینگ، Backup و بازیابی چه برنامه‌ای دارید؟
• ارتقا یا تغییر پلن با چه فرایند و چه Downtime احتمالی انجام می‌شود؟
• کدام شاخص‌ها و نمودارها از داخل پنل یا سیستم‌عامل در دسترس هستند؟

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

گزارش حرفه‌ای برای پشتیبانی چه اطلاعاتی داشته باشد؟

گزارش دقیق زمان حل را کوتاه می‌کند. به‌جای «سرور کند است»، بازه زمانی و نشانه قابل تکرار بدهید. اطلاعات حساس مانند رمز، Token، Cookie، کلید خصوصی و داده مشتری را حذف کنید.

• شناسه سرویس و سیستم‌عامل، بدون افشای اطلاعات ورود؛
• تاریخ و ساعت دقیق رخداد به وقت تهران و در صورت امکان UTC؛
• شرح اثر: Timeout، کندی SSH، خطای وب یا عقب‌ماندن Queue؛
• خروجی چند نمونه uptime، vmstat، free و در صورت دسترسی iostat؛
• نام پردازه یا سرویس مرتبط و تغییرات اخیر؛
• وجود یا نبود بکاپ، Import، Update و کمپین ترافیکی در همان زمان؛
• گام‌های بازتولید و نتیجه‌ای که انتظار داشتید.

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

عیب‌یابی دستی برای رخداد زنده ضروری است، اما مشکل‌های متناوب معمولاً پیش از ورود مدیر تمام می‌شوند. یک سامانه پایش باید هم داده‌های سطح سیستم و هم شاخص‌های سرویس را با Timestamp مشترک نگه دارد. حداقل نمودارها شامل Load، زمان CPU در حالت‌های user/system/iowait/steal، حافظه Available، Swap in/out، Latency و صف دیسک، فضای فایل‌سیستم، ترافیک شبکه، زمان پاسخ و نرخ خطای برنامه است. رزولوشن نمونه‌برداری باید آن‌قدر باشد که Burst کوتاه را از دست ندهد، اما جمع‌آوری داده نیز نباید خود به بار سنگین تبدیل شود.

Alert خوب بر یک عدد خام بنا نمی‌شود. برای نمونه، Load بالا وقتی ارزش هشدار فوری دارد که چند دقیقه ادامه پیدا کند و هم‌زمان Latency یا Queue رشد کند. هشدار RAM نیز بهتر است به Available، Memory Pressure یا Swap Activity وابسته باشد، نه صرفاً درصد Used. آستانه‌ها را از خط مبنای خود استخراج کنید و برای هر Alert یک Runbook کوتاه داشته باشید: چه کسی بررسی می‌کند، نخستین فرمان‌های خواندنی چیست، چه شواهدی ثبت می‌شود و چه زمانی Escalation انجام می‌شود.

نمونه‌برداری دوره‌ای با ابزارهای سیستم

ابزارهایی مانند sar در مجموعه sysstat می‌توانند تاریخچه CPU، Load، Memory، Swap، I/O و شبکه را نگه دارند؛ ولی فعال‌سازی، فاصله نمونه و مدت نگهداری در هر توزیع متفاوت است. قبل از نصب یا تغییر، فضای مصرفی و سیاست نگهداری را بررسی کنید. اگر از سرویس مانیتورینگ خارجی استفاده می‌کنید، Agent و سطح دسترسی آن را ارزیابی و از ارسال Secret، آرگومان حساس فرمان یا محتوای کاربران جلوگیری کنید.

استفاده از PSI برای دیدن فشار واقعی منابع

Pressure Stall Information یا PSI نشان می‌دهد کمبود CPU، حافظه یا I/O چه مقدار از زمان اجرای کارها را متوقف کرده است. فایل‌های /proc/pressure/cpu، memory و io در Kernelهای پشتیبان‌شده، میانگین فشار را ارائه می‌کنند. مقدار some زمانی را بیان می‌کند که حداقل بخشی از Taskها متوقف بوده‌اند؛ برای Memory و I/O، مقدار full شرایطی را نشان می‌دهد که همه کارهای غیر‌بیکار هم‌زمان متوقف‌اند. PSI جای Latency برنامه را نمی‌گیرد، اما حلقه ارتباط میان کمبود منبع و توقف کار واقعی را روشن‌تر می‌کند.

لود بالا در Docker و cgroup چه تفاوتی دارد؟

اگر برنامه در Container اجرا می‌شود، وضعیت کل ماشین و محدودیت Container را جدا ببینید. یک Container می‌تواند به سقف CPU یا Memory خود برسد، درحالی‌که Host هنوز ظرفیت آزاد دارد. برعکس، چند Container بدون حد مناسب می‌توانند روی یکدیگر اثر بگذارند. آمار docker stats نمای اولیه می‌دهد، اما برای تشخیص دقیق باید محدودیت CPU، Memory، OOM Event و Restart Policy را با تنظیمات Compose یا Orchestrator تطبیق دهید.

CPU Throttling با CPU Usage یکسان نیست

وقتی سهم CPU یک cgroup محدود شده، Task ممکن است پس از مصرف سهم دوره‌ای Throttle شود. در این وضعیت، درصد CPU مشاهده‌شده ممکن است به سقف تعریف‌شده برسد ولی کل سرور بیکار به نظر برسد. افزایش Worker داخل Container راه‌حل نیست و حتی صف را بزرگ‌تر می‌کند. ابتدا محدودیت، درخواست واقعی برنامه و Counterهای Throttling را بررسی کنید؛ سپس میان بهینه‌سازی، تغییر Limit و توزیع بار تصمیم بگیرید.

OOM در Container و OOM در کل سرور

OOM داخل cgroup ممکن است فقط همان Container را تحت تأثیر قرار دهد. Restart خودکار باعث می‌شود مشکل شبیه قطعی کوتاه و تصادفی دیده شود. تعداد Restart، Exit Code، OOM Flag و مصرف قبل از توقف را ثبت کنید. افزایش Limit بدون یافتن دلیل رشد حافظه ممکن است فقط زمان رخداد بعدی را عقب بیندازد. همچنین Limit بسیار نزدیک به مصرف معمول، حاشیه Burst و Cache Runtime را حذف می‌کند.

از شاخص سیستم به علت برنامه برسید

سیستم‌عامل نشان می‌دهد کدام منبع تحت فشار است؛ اما معمولاً نمی‌گوید کدام رفتار کسب‌وکار آن را ساخته است. برای وب‌سرور، زمان پاسخ و Status Code را براساس Route بررسی کنید. برای دیتابیس، Slow Query، Lock، تعداد اتصال و Buffer Pool را ببینید. برای Queue، زمان انتظار، نرخ ورود و خروج و Retry مهم است. برای API خارجی، Timeout و Circuit Breaker را بسنجید. اتصال این داده‌ها به یک Trace یا Request ID، تشخیص را از حد حدس بالاتر می‌برد.

دیتابیس: CPU، I/O یا Lock؟

مصرف بالای دیتابیس می‌تواند سه چهره متفاوت داشته باشد. Query محاسباتی CPU را مصرف می‌کند؛ Scan بزرگ و Flush می‌تواند I/O بسازد؛ Lock باعث می‌شود درخواست‌ها منتظر بمانند، حتی اگر CPU پایین باشد. قبل از افزایش منابع، Queryهای کند، Execution Plan، Index، تعداد اتصال و تراکنش طولانی را بررسی کنید. افزایش Connection Limit بدون ظرفیت کافی ممکن است رقابت حافظه و دیسک را شدیدتر کند.

وب‌سرور و Workerها: صف را به لایه بعدی منتقل نکنید

افزایش Worker زمانی مفید است که CPU، RAM و Backend ظرفیت پاسخ‌گویی داشته باشند و محدودیت صرفاً هم‌زمانی Frontend باشد. اگر دیتابیس یا API کند است، Worker بیشتر می‌تواند اتصال‌های منتظر و مصرف حافظه را افزایش دهد. تعداد Worker را با زمان پاسخ، حافظه هر Process، Keep-Alive، نرخ درخواست و ظرفیت Backend تنظیم کنید و پس از تغییر Load Test کنترل‌شده بگیرید.

تغییرات امن در زمان حادثه

در لحظه کندی، فشار برای اقدام سریع زیاد است؛ اما تغییر نامستند می‌تواند حادثه دوم بسازد. ابتدا وضعیت را ثبت کنید، سپس بین اقدام کاهش اثر و رفع ریشه‌ای فرق بگذارید. محدودکردن موقت یک Job، خارج‌کردن Route پرهزینه از دسترس یا کاهش هم‌زمانی می‌تواند اثر را کم کند؛ ولی باید زمان انقضا و مسئول بازگردانی مشخص داشته باشد. هر دستور نوشتنی، Restart، تغییر Kernel Parameter یا پاک‌سازی فایل باید با Backup، دامنه اثر و Rollback روشن انجام شود.

نوع اقدام	هدف	کنترل لازم
جمع‌آوری Snapshot	حفظ شواهد پیش از تغییر	فرمان‌های خواندنی و حذف اطلاعات حساس
کاهش موقت بار	بازگرداندن سرویس	زمان انقضا، مالک اقدام و اثر بر کاربران
Restart کنترل‌شده	بازیابی Process قفل‌شده	ثبت وضعیت، سلامت وابستگی و آزمون پس از اجرا
بهینه‌سازی ریشه‌ای	جلوگیری از تکرار	Staging، Load Test، Backup و Rollback
ارتقای منابع	پوشش بار سالم و رشد	شواهد ظرفیت، حاشیه امن و برنامه مهاجرت

جمع‌بندی

برای رفع لود بالای سرور مجازی، ابتدا اثر واقعی روی سرویس را اندازه بگیرید، سپس Load را با تعداد هسته و روند زمانی تفسیر کنید. اگر CPU و Run Queue بالا هستند، پردازه و درخواست مولد بار را پیدا کنید. اگر CPU بیکار ولی Load بالا است، iowait و Taskهای Blocked را بررسی کنید. برای حافظه، Available، نرخ Swap، PSI و OOM از درصد خام RAM مهم‌ترند. در ماشین مجازی، Steal Time نیز باید در همان بازه سنجیده شود.

بهترین تصمیم، نتیجه یک زنجیره شواهد است: مشکل کاربر، Timestamp، شاخص سیستم، عامل تولید بار، تغییر کنترل‌شده و آزمون مجدد. اگر پس از بهینه‌سازی، بار سالم و ضروری همچنان ظرفیت را پر می‌کند، ارتقای سرور مجازی تصمیمی فنی و فروش‌پذیر است؛ نه واکنشی به یک عدد لحظه‌ای.

سؤالات متداول درباره لود بالای سرور مجازی

منابع فنی برای مطالعه بیشتر

• مستندات رسمی proc در Linux Kernel
• راهنمای رسمی CPU Load در Linux Kernel
• مستندات Pressure Stall Information
• صفحه راهنمای uptime
• صفحه راهنمای vmstat
• صفحه راهنمای iostat