چقدر RAM و CPU برای سرور مجازی لازم است؟
انتخاب مبتنی بر workload و اندازه‌گیری

از workload شروع کنید، نه از نام پلن

اجزای واقعی را بنویسید: سیستم‌عامل، وب‌سرور، runtime، worker، دیتابیس، cache، agent مانیتورینگ و jobهای backup. تعداد کاربر آنلاین به‌تنهایی کافی نیست؛ نرخ request، زمان هر request، concurrency، اندازه working set دیتابیس و jobهای پس‌زمینه تعیین‌کننده‌اند. حداقل رسمی نسخه دقیق نرم‌افزار نقطه شروع است، نه ظرفیت production.

بار را به سه وضعیت تقسیم کنید: idle، عادی و اوج. اوج فروش، import، build یا backup ممکن است با ترافیک عادی هم‌زمان شود. اگر چند سرویس را روی یک VPS جمع می‌کنید، جمع حداقل‌هایشان هم کافی نیست؛ رقابت CPU، RAM و I/O و failure مشترک را نیز در نظر بگیرید.

چه زمانی CPU گلوگاه است؟

vCPU بیشتر برای کار موازی مفید است، اما یک task تک‌رشته‌ای از هسته‌های بیشتر الزاماً سریع‌تر نمی‌شود و به عملکرد هر هسته وابسته است. نشانه‌های فشار CPU شامل استفاده پایدار نزدیک ظرفیت، queue شدن کار، افزایش latency هم‌زمان با load و طولانی‌شدن jobهاست. load average را نسبت به تعداد vCPU و نوع task تفسیر کنید؛ task منتظر I/O نیز می‌تواند در load دیده شود.

در Linux از uptime، top، vmstat 1 و در صورت دسترس از PSI در /proc/pressure/cpu کمک بگیرید. یک snapshot کوتاه کافی نیست؛ درصدها را با latency برنامه و بازه اوج هم‌بسته کنید. کد ناکارا، query بد یا loop نیز با خرید هسته بیشتر فقط پنهان می‌شود.

چه زمانی RAM کم است؟

در Linux مقدار free پایین همیشه کمبود RAM نیست، چون kernel حافظه بلااستفاده را برای cache به‌کار می‌گیرد. available، working set پردازش‌ها، swap in/out، memory pressure و logهای OOM را با هم ببینید. swap می‌تواند از crash ناگهانی جلوگیری کند، اما فعالیت مداوم آن زیر بار تعاملی معمولاً با latency بالا همراه است.

free -h نمای کلی و vmstat 1 حرکت swap را نشان می‌دهد؛ /proc/pressure/memory زمان توقف taskها به علت فشار حافظه را اندازه می‌گیرد. memory leak را با رشد پیوسته در زمان از cache سالم جدا کنید. افزایش RAM بدون تعیین سقف cache یا worker ممکن است فقط زمان رسیدن به مشکل را عقب بیندازد.

بر اساس نوع کار، کدام منبع معمولاً حساس‌تر است؟

• وب‌سایت cacheشده: concurrency و runtime را بسنجید؛ cache می‌تواند CPU و دیتابیس را کم کند ولی خودش RAM می‌خواهد.
• دیتابیس: working set، buffer/cache، query و I/O به هم وابسته‌اند؛ RAM بیشتر جای index و query مناسب را نمی‌گیرد.
• worker و پردازش batch: تعداد worker را با vCPU و حافظه هر job محدود کنید؛ concurrency بی‌مهار هر دو منبع را اشباع می‌کند.
• Windows و GUI: سربار سیستم‌عامل و برنامه دسکتاپ را در baseline واقعی اندازه بگیرید و تنها به حداقل نصب اکتفا نکنید.
• کانتینرها: مجموع request/limit و سرویس‌های میزبان را لحاظ کنید؛ تعداد کانتینر معیار مستقیمی برای RAM یا CPU نیست.

این الگوها جهت تشخیص‌اند و عدد ثابت پلن نیستند. راهنمای سازنده نرم‌افزار و benchmark نسخه خودتان بر هر جدول عمومی اولویت دارد.

آزمون ظرفیت را چطور طراحی کنیم؟

داده و مسیرهای واقعی را با اطلاعات حساس حذف‌شده در محیط نماینده اجرا کنید. بار را تدریجی بالا ببرید و هم‌زمان latency صدکی، throughput، error rate، CPU، RAM، pressure و I/O را ثبت کنید. هدف فقط پیدا کردن بیشترین request نیست؛ باید نقطه‌ای را پیدا کنید که SLO برنامه هنوز رعایت می‌شود و سرویس پس از spike بازیابی می‌شود.

backup، deploy، log rotation و job شبانه را در سناریو بگنجانید. آزمون کوتاه memory leak و گرم‌شدن cache را نشان نمی‌دهد؛ soak test نیز لازم است. هر بار فقط یک متغیر مانند worker count یا vCPU را تغییر دهید تا علت بهبود یا افت معلوم بماند.

انتخاب اولیه و بازبینی پس از خرید

کوچک‌ترین گزینه‌ای را انتخاب کنید که حداقل رسمی، اوج آزموده‌شده و حاشیه‌ای برای نوسان را پوشش دهد. اگر downtime ارتقا برای کسب‌وکار مهم است، مسیر scale و زمان لازم را پیشاپیش بپرسید. CPU، RAM، disk و شبکه را مستقل نبینید؛ برنامه منتظر دیسک با افزودن CPU حل نمی‌شود.

بعد از راه‌اندازی، baseline هفته اول و هشدارهای نزدیک ظرفیت را ثبت کنید. تصمیم ارتقا باید بر روند و اثر کاربر تکیه کند: latency، error و pressure. منابع بسیار زیاد بدون monitor هزینه را بالا می‌برد؛ منابع لب‌مرز نیز هر spike را به اختلال تبدیل می‌کند. اندازه‌گذاری یک چرخه مشاهده، اصلاح و آزمون است.