پاسخ کوتاه
۴ گیگابایت برای سرویس سبک و بهینه مناسب است؛ ۸ گیگابایت برای دیتابیس، چند Container، فروشگاه یا رشد نزدیک حاشیه امن بیشتری می‌دهد.
باید مجموع RSS سرویس‌ها، Cache دیتابیس، Page cache و پیک Deploy را بسنجید. RAM بلااستفاده می‌تواند Cache مفید باشد، ولی ظرفیت بیش‌ازحد نیز هزینه دارد.
چرا یک عدد ثابت جواب نمی‌دهد؟
دو برنامه با تعداد کاربر برابر می‌توانند منابع کاملاً متفاوتی بخواهند. Cache، تعداد Request هم‌زمان، Query، اندازه پاسخ، Job پس‌زمینه و درصد نوشتن در دیتابیس روی مصرف اثر می‌گذارند. بنابراین «بازدید ماهانه» یا نام Framework به‌تنهایی ورودی خوبی برای خرید نیست.
هدف باید تجربه کاربر و پایداری باشد: p95 زمان پاسخ، نرخ خطا، زمان Queue، ظرفیت Connection و زمان بازیابی. منابع وسیله رسیدن به این هدف‌اند، نه خود هدف.
بار کاری خود را توصیف کنید
یک روز عادی و یک ساعت پیک را جدا بنویسید. تعداد Request، کاربر هم‌زمان، حجم و رشد داده، نسبت خواندن به نوشتن، Jobهای زمان‌بندی‌شده و Dependencyهای خارجی را مشخص کنید. همچنین معلوم کنید چه مقدار قطعی قابل قبول است.
اگر سرویس موجود دارید، حدس نزنید؛ حداقل یک هفته متریک بگیرید. اگر پروژه جدید است، با سناریوی کوچک Load test و فرضیات صریح شروع کنید تا بعداً بتوانید آن‌ها را با داده واقعی جایگزین کنید.
منابع را چطور کنار هم ببینیم؟
CPU سریع برای کار تک‌رشته‌ای، Core بیشتر برای کار موازی، RAM برای Working set و Cache، دیسک کم‌تأخیر برای I/O و شبکه مناسب برای کاربر و Dependency لازم است. گلوگاه یکی از این‌ها می‌تواند بقیه منابع آزاد را بی‌اثر کند.
- در 4 GB تعداد Workerها و DB buffer باید محدود باشد.
- 8 GB امکان جداسازی و Cache بیشتر می‌دهد.
- Resizeپذیری ریسک شروع کوچک را کم می‌کند.
نقطه شروع و روش اندازه‌گیری
اگر پیک available کمتر از ۱۵ تا ۲۰ درصد، Swap فعال یا OOM دارید به ۸ GB بروید؛ در غیر این صورت ابتدا Leak و تنظیمات را اصلاح کنید.
پلنی انتخاب کنید که Resize آن روشن و کم‌ریسک باشد. پس از راه‌اندازی، CPU هر Core، available memory و Swap، latency دیسک، Connectionها و p95 پاسخ را در پیک ثبت کنید. عدد شروع حکم نهایی نیست؛ یک فرض مهندسی قابل آزمون است.
Load test درست چه شکلی است؟
سناریو باید رفتار واقعی را تقلید کند: ترکیب Endpointها، Login، Cache warm/cold، خواندن و نوشتن و زمان فکر کاربر. افزایش بار را مرحله‌ای انجام دهید و نقطه‌ای را ثبت کنید که latency یا error به‌سرعت رشد می‌کند.
تست را روی Production فعال و بدون سقف اجرا نکنید. داده آزمایشی، محدودیت نرخ، پنجره مشخص و مانیتورینگ کامل لازم است. نتیجه باید علاوه بر حداکثر ظرفیت، حاشیه امن و رفتار زمان خرابی Dependency را نشان دهد.
هزینه واقعی و قابلیت اطمینان
قیمت پلن فقط بخشی از هزینه است. Backup، ترافیک خروجی، IP، License، مانیتورینگ، زمان نگهداری و هزینه قطعی را هم حساب کنید. گاهی دو سرور متوسط با Failover از یک سرور بسیار بزرگ ارزش عملیاتی بیشتری دارند.
همچنین دامنه خرابی را بشناسید. چند ماشین روی یک میزبان، چند دیسک در یک Array یا Backup در همان حساب ممکن است ظاهراً چند نسخه باشند اما از یک حادثه مشترک آسیب ببینند.
چه زمانی ارتقا یا مهاجرت کنیم؟
اگر در چند پیک متوالی CPU یا I/O اشباع، available memory کم، Swap فعال، Queue رو به رشد یا p95 خارج از هدف دارید و بهینه‌سازی واضحی باقی نمانده، ارتقا منطقی است. برای بار فصلی، مقیاس‌پذیری موقت ممکن است بهتر از خرید ظرفیت دائمی باشد.
پیش از مهاجرت، Benchmark مقصد، روش انتقال داده، زمان همگام‌سازی، TTL، Cutover و Rollback را آزمایش کنید. تصمیم ظرفیت بدون برنامه مهاجرت می‌تواند ریسک بیشتری از کمبود فعلی ایجاد کند.
اشتباه رایج
انتخاب ۸ GB برای پوشاندن Memory leak یا تعداد Worker نامحدود، فقط زمان حادثه را عقب می‌اندازد.
منابع بیشتر می‌توانند یک Query بد، Memory leak یا معماری تک‌نقطه‌ای را مدتی پنهان کنند؛ اما مشکل را حذف نمی‌کنند. هزینه را فقط وقتی بالا ببرید که داده نشان دهد گلوگاه واقعاً همان منبع است.
پرسش‌های مهمی که قبل از اقدام باید جواب دهید
برای اینکه پاسخ «4GB یا 8GB RAM؛ کدام را انتخاب کنیم؟» فقط در حد اطلاعات عمومی نماند، ابتدا وضعیت فعلی خود را با عدد توصیف کنید: نسخه سیستم‌عامل یا نرم‌افزار، تعداد کاربر هم‌زمان، مصرف معمول و اوج منابع، حجم و رشد داده، محدودیت شبکه و بیشترین قطعی قابل قبول. بدون این اطلاعات ممکن است توصیه‌ای که از نظر فنی درست است، برای محیط شما انتخاب مناسبی نباشد.
دو سؤال بعدی مستقیماً از نکات این موضوع می‌آیند: «در 4 GB تعداد Workerها و DB buffer باید محدود باشد.» در زیرساخت شما چگونه اندازه‌گیری یا تأیید می‌شود؟ و «8 GB امکان جداسازی و Cache بیشتر می‌دهد.» چه اثری روی کاربر، هزینه یا مسیر بازیابی دارد؟ پاسخ را در قالب شواهدی مانند خروجی فرمان، نمودار متریک، نتیجه آزمون یا مستند ارائه‌دهنده ثبت کنید؛ اتکا به حافظه و حدس برای تصمیم عملیاتی کافی نیست.
یک برنامه عملی کم‌ریسک
کار را با ثبت وضعیت فعلی و یک معیار موفقیت آغاز کنید. سپس پیشنهاد اصلی این راهنما را در کوچک‌ترین محیط نماینده اجرا کنید: اگر پیک available کمتر از ۱۵ تا ۲۰ درصد، Swap فعال یا OOM دارید به ۸ GB بروید؛ در غیر این صورت ابتدا Leak و تنظیمات را اصلاح کنید. نتیجه را در حالت عادی و در یک سناریوی خطا یا فشار کنترل‌شده بسنجید. اگر معیار بهتر نشد، به‌جای افزودن تغییرات بیشتر، فرض اولیه را بازبینی کنید.
پیش از اعمال تغییر در سرویس اصلی، روش بازگشت، مسئول تصمیم و زمان توقف را روشن کنید. این هشدار را نیز به‌عنوان شرط توقف در نظر بگیرید: انتخاب ۸ GB برای پوشاندن Memory leak یا تعداد Worker نامحدود، فقط زمان حادثه را عقب می‌اندازد. پس از اجرا، نتیجه، نسخه‌ها و تنظیمات مؤثر را مستند کنید و یک زمان بازبینی تعیین کنید؛ تغییر بدون پایش ممکن است امروز سالم به نظر برسد اما در پیک بعدی شکست بخورد.
- در 4 GB تعداد Workerها و DB buffer باید محدود باشد.
- 8 GB امکان جداسازی و Cache بیشتر می‌دهد.
- Resizeپذیری ریسک شروع کوچک را کم می‌کند.
جمع‌بندی و چک‌لیست خرید
برای پاسخ به «4GB یا 8GB RAM؛ کدام را انتخاب کنیم؟» این موارد را کنار هم بگذارید: بار عادی و پیک، معیار latency و خطا، CPU، RAM، I/O، شبکه، رشد داده، Backup، دامنه خرابی، امکان Resize و هزینه کل. با یک نقطه شروع منطقی آغاز کنید و زمان بازبینی را از همان روز اول تعیین کنید.
- در 4 GB تعداد Workerها و DB buffer باید محدود باشد.
- 8 GB امکان جداسازی و Cache بیشتر می‌دهد.
- Resizeپذیری ریسک شروع کوچک را کم می‌کند.