منابع مورد نیاز سرور مجازی، به‌ویژه CPU و RAM، را باید از مصرف برنامه در زمان شلوغی، تعداد کارهای هم‌زمان و کیفیت پاسخ‌گویی مورد انتظار به دست آورد. برای پروژه فعال، اندازه‌گیری نقطه شروع است؛ برای پروژه تازه، یک پیکربندی آزمایشی بسازید و آن را زیر بار مشابه استفاده واقعی بسنجید. حداقل منابع لازم برای نصب نرم‌افزار، لزوماً منابع کافی برای خدمت‌رسانی به کاربران نیست.
برای تخمین منابع مورد نیاز سرور مجازی، لازم نیست از ابتدا پیش‌بینی دقیقی از تمام رشد آینده داشته باشید. یک برآورد قابل توضیح، آزمون مناسب و امکان بازبینی، تصمیم بهتری از خرید منابع زیاد بر اساس حدس می‌سازد. در این راهنما، روش تخمین حافظه و پردازنده را با مثال عددی بررسی می‌کنیم و نشان می‌دهیم چه زمانی ارتقا منطقی است.
پیش از انتخاب پلن، بار کاری را مشخص کنید
بار کاری یعنی مجموعه کارهایی که برنامه انجام می‌دهد؛ از نمایش یک صفحه تا جست‌وجو در پایگاه داده، تولید گزارش یا پردازش تصویر. تعداد بازدید روزانه به‌تنهایی این تفاوت‌ها را نشان نمی‌دهد. دو سایت با بازدید یکسان می‌توانند نیاز پردازشی متفاوتی داشته باشند.
فهرست نرم‌افزارها و نسخه‌هایشان، محل اجرای پایگاه داده، سرویس‌های پس‌زمینه و عملیات سنگین را بنویسید. مشخص کنید چه کارهایی هم‌زمان رخ می‌دهند: مثلاً آیا تهیه بکاپ با اوج فروش هم‌پوشانی دارد؟ آیا وب‌سرور، پایگاه داده و پردازش گزارش روی یک ماشین اجرا می‌شوند؟
سپس یک معیار عملی برای موفقیت انتخاب کنید. در یک فروشگاه فرضی، معیار می‌تواند تکمیل ثبت سفارش در زمان قابل قبول و بدون افزایش خطا باشد. در پردازش دسته‌ای، تمام‌شدن کار پیش از موعد اهمیت دارد. این معیارها کمک می‌کنند مصرف بالای CPU را در ارتباط با نتیجه برنامه تفسیر کنید.
تخمین RAM در منابع مورد نیاز سرور مجازی
مصرف پایه و مصرف هنگام شلوغی را جدا ببینید
حافظه را فقط برای برنامه اصلی در نظر نگیرید. سیستم‌عامل، وب‌سرور، پایگاه داده، کنترل‌پنل، ابزارهای پایش و کارهای پس‌زمینه هم سهم دارند. ابتدا مصرف پایه را ثبت کنید؛ سپس ببینید با افزایش درخواست‌های هم‌زمان چه مقدار به مصرف اضافه می‌شود.
اگر برنامه چند پردازش مشابه برای پاسخ‌گویی دارد، تعداد این پردازش‌ها و مصرف هرکدام در زمان بار اهمیت پیدا می‌کند. اما جمع ساده حافظه گزارش‌شده همه پردازش‌ها همیشه دقیق نیست؛ بخش‌های مشترک حافظه ممکن است چند بار شمرده شوند. مجموع را با سنجه‌های کل ماشین و رفتار برنامه تطبیق دهید.
پایگاه داده نیز فقط به یک عدد ثابت محدود نمی‌شود. برای نمونه، در PostgreSQL بعضی عملیات هر پرس‌وجو و نشست‌های هم‌زمان می‌توانند جداگانه حافظه مصرف کنند؛ بنابراین مقدار یک تنظیم مثل work_mem، سقف کل مصرف پایگاه داده نیست. این موضوع در مستندات مصرف منابع PostgreSQL توضیح داده شده است. برای نرم‌افزار خودتان، محدودیت‌ها و مصرف هم‌زمان را از مستندات همان نسخه بررسی کنید.
یک نمونه محاسبه RAM
فرض کنید برای یک برنامه آزمایشی، مصرف اجزای جدا از هم در زمان اوج بار به شکل زیر برآورد شده است. اعداد صرفاً برای توضیح روش‌اند؛ نه اندازه‌گیری یک مشتری و نه پیشنهاد عمومی برای همه سایت‌ها. همه مقادیر جدول با یک مبنای واحد حافظه محاسبه شده‌اند.
| بخش | فرض مصرف در مثال | نکتهٔ محاسبه |
|---|---|---|
| سیستم‌عامل و سرویس‌های پایه | ۰٫۸ گیگابایت | شامل وب‌سرور و ابزار پایش |
| پایگاه داده و کش برنامه | ۱ گیگابایت | مصرف هنگام بار، بدون تکرار سهم بالا |
| پردازش‌های پاسخ‌گو | ۱٫۲ گیگابایت | ۸ پردازش، هرکدام حدود ۰٫۱۵ گیگابایت |
| مجموع برآورد | ۳ گیگابایت | پیش از افزودن حاشیهٔ ظرفیت |
اگر در همین مثال ۲۵ درصد به برآورد اضافه کنیم، به ۳٫۷۵ گیگابایت می‌رسیم. بنابراین پیکربندی ۴ گیگابایتی می‌تواند نامزد آزمون باشد؛ هنوز نمی‌توان گفت برای بهره‌برداری کافی است. بارهای گذرا، رشد کش و عملیات نگهداری باید در آزمون پوشش داده شوند. همچنین واحد GB و GiB را در مشخصات سرویس و ابزار اندازه‌گیری یکسان‌سازی کنید؛ این دو دقیقاً برابر نیستند.
حاشیه ۲۵ درصد یک فرض آموزشی است. برای بار نوسانی، تأخیر زیاد در ارتقا یا توقف پرهزینه، ممکن است ظرفیت بیشتری لازم باشد. برای سرویس قابل پیش‌بینی با امکان بازبینی سریع، می‌توان محافظه‌کارانه‌تر هزینه کرد. مقدار حاشیه را با ریسک پروژه و نتیجه آزمون تعیین کنید.
محصولات ابر آراد را ببینید و مشخصات هر سرویس را مقایسه کنید.
کم‌بودن حافظه آزاد همیشه نشانه کمبود RAM نیست
در لینوکس، بخشی از حافظه برای کش استفاده می‌شود و همه آن الزاماً از دسترس برنامه‌های جدید خارج نشده است. در خروجی ابزار free، ستون available برآورد بهتری از حافظه قابل استفاده برای شروع برنامه‌های جدید بدون جابه‌جایی به swap می‌دهد. تعریف دقیق ستون‌ها در راهنمای ابزار free آمده است.
کمبود مداوم حافظه قابل استفاده، افزایش جابه‌جایی داده با swap همراه با افت عملکرد و خطاهای کمبود حافظه را کنار هم بررسی کنید. صرف وجود داده در swap، به‌تنهایی حکم ارتقا نیست. اگر مصرف با گذر زمان بالا می‌رود و پس از کاهش بار پایین نمی‌آید، احتمال نشتی حافظه یا تنظیم نامناسب را هم بررسی کنید؛ RAM بیشتر ممکن است فقط بروز مشکل را عقب بیندازد.
CPU را با مصرف در اوج بار و توان اجرای هم‌زمان بسنجید
vCPU واحد پردازشی ارائه‌شده به ماشین مجازی است. تعداد آن به‌تنهایی عملکرد را تعیین نمی‌کند؛ مدل تخصیص، پردازنده میزبان و رفتار برنامه هم مؤثرند.
نمودار کل CPU را همراه با مصرف هر پردازنده مجازی ببینید. ممکن است یک بخش برنامه فقط از یک رشته اجرایی استفاده کند؛ در این حالت، یک vCPU اشباع می‌شود ولی میانگین کل پایین می‌ماند. اضافه‌کردن تعداد vCPU الزاماً همان بخش را سریع‌تر نمی‌کند. در مقابل، برنامه‌ای که چند کار مستقل را هم‌زمان اجرا می‌کند، ممکن است از ظرفیت پردازشی بیشتر بهره ببرد.
یک برآورد اولیه برای تغییر تعداد vCPU
فرض کنید برنامه‌ای روی ۲ vCPU، در بار نماینده زمان شلوغی، به‌طور پایدار ۷۰ درصد ظرفیت کل پردازنده را مصرف می‌کند. اگر برای همین بار، هدف آزمایشی مصرف ۵۰ درصد باشد، برآورد اولیه از ضرب ۲ در ۰٫۷ و تقسیم حاصل بر ۰٫۵ به دست می‌آید: حدود ۲٫۸ vCPU. در صورت عرضه پلن‌های ۲ و ۴ پردازنده‌ای، پلن ۴ vCPU نامزد مقایسه است.
این محاسبه فقط یک تخمین متناسب است: پردازنده و مدل تخصیص باید قابل مقایسه باشند، بار ثابت بماند و برنامه بتواند از ظرفیت اضافه استفاده کند. همچنین سنجه ۷۰ درصد باید نسبت به کل ظرفیت ماشین تعریف شده باشد؛ درصدهای بعضی ابزارها برای یک پردازش یا یک هسته معنای دیگری دارند. عدد ۵۰ درصد هم هدف فرضی این مثال است، نه آستانه استاندارد خرید.
اگر CPU قبلی دائماً اشباع بوده و درخواست‌ها در صف مانده‌اند، مصرف مشاهده‌شده تمام تقاضای واقعی را نشان نمی‌دهد. در این وضعیت، یا وقتی قفل پایگاه داده، دیسک یا سرویس بیرونی عامل انتظار است، با این محاسبه نمی‌توان ظرفیت نهایی را تعیین کرد. پیکربندی جدید را با همان سناریوی واقعی آزمایش کنید.
اگر پروژه تازه است، از کجا شروع کنیم؟
حداقل و مقدار پیشنهادی نرم‌افزارهای اصلی را از مستندات نسخه مورد استفاده جمع کنید. سپس مصرف اجزایی را که روی همان ماشین اجرا می‌شوند کنار هم بگذارید و یک پیکربندی قابل تغییر برای آزمایش انتخاب کنید. جدول زیر مشخص می‌کند در هر نوع پروژه کدام آزمون زودتر به تصمیم کمک می‌کند.
| نوع پروژه | چه چیزی را ابتدا بسنجید؟ | خطایی که باید از آن پرهیز کنید |
|---|---|---|
| سایت محتوایی با کش | بار صفحات کش‌شده و کش‌نشده | یکسان‌گرفتن همهٔ بازدیدها |
| فروشگاه یا برنامهٔ تعاملی | ورود، جست‌وجو، سبد و ثبت سفارش | آزمون صرفاً روی صفحهٔ اصلی |
| پایگاه داده | دادهٔ فعال، پرس‌وجو و اتصال هم‌زمان | برابرگرفتن حجم دیسک با RAM لازم |
| پردازش دسته‌ای | زمان پایان کار و حافظهٔ هر کار | افزایش هم‌زمانی بدون ظرفیت کافی |
اگر تنها اطلاعات شما «تعداد کاربر ثبت‌نام‌شده» است، هنوز مبنای کافی برای انتخاب منابع ندارید. تعداد کاربران فعال، نرخ درخواست و نوع عملیات را تخمین بزنید. تعداد کاربر با تعداد درخواست در ثانیه یا تعداد پردازش هم‌زمان برابر نیست؛ رفتار کاربران و زمان پاسخ برنامه میان این اعداد ارتباط ایجاد می‌کند.
تخمین را با آزمون بار به تصمیم خرید تبدیل کنید
آزمون را در محیط مجاز و ترجیحاً جدا از سرویس اصلی، با داده و تنظیمات نزدیک به بهره‌برداری انجام دهید. بار را تدریجی بالا ببرید و در هر مرحله زمانی برای مشاهده رفتار پایدار بدهید. عملیات سنگین، وضعیت کش و کارهای دوره‌ای مرتبط را هم پوشش دهید. مطمئن شوید خود ابزار تولید بار به محدودیت منابع نرسیده است.
در هر مرحله، نرخ درخواست تکمیل‌شده، خطاها، زمان پاسخ، CPU و حافظه را کنار هم ثبت کنید. میانگین زمان پاسخ ممکن است کندی بخشی از درخواست‌ها را پنهان کند؛ صدک ۹۵ زمانی است که حدود ۹۵ درصد پاسخ‌ها در آن یا زودتر تکمیل شده‌اند. در مستندات آستانه‌های آزمون Grafana k6 می‌توانید روش تعیین معیار قبول یا رد آزمون را ببینید. آستانه را از نیاز برنامه بگیرید، نه از عدد نمونه یک ابزار.
وقتی در بار هدف، کیفیت پاسخ‌گویی مناسب است و برای نوسان بار ظرفیت دارید، پیکربندی به انتخاب قابل دفاع نزدیک شده است. اگر عملکرد نامناسب است، ابتدا عامل محدودکننده را پیدا کنید و یک تغییر مشخص انجام دهید؛ سپس آزمون را با شرایط قابل مقایسه تکرار کنید.
چه زمانی ارتقای منابع منطقی است؟
افزایش RAM زمانی توجیه دارد که شواهد فشار حافظه با افت کیفیت سرویس هم‌زمان باشند و مصرف موردنیاز برنامه قابل توضیح باشد. افزایش CPU زمانی مناسب است که پردازش عامل محدودکننده باشد و برنامه بتواند از ظرفیت اضافه استفاده کند. اگر زمان عمدتاً صرف انتظار دیسک، قفل نرم‌افزاری یا پاسخ شبکه می‌شود، ابتدا همان مسیر را بررسی کنید.
پس از راه‌اندازی هم تصمیم را بازبینی کنید: تغییر نسخه نرم‌افزار، افزونه تازه، رشد داده یا کمپین تبلیغاتی می‌تواند الگوی مصرف را عوض کند. کاهش منابع را نیز فقط از روی یک ساعت خلوت انجام ندهید؛ یک چرخه کاری نماینده را بررسی کنید و امکان بازگشت را در نظر بگیرید.
برای افزایش CPU و RAM در ابر آراد، شرایط پلن و پشتیبانی از Hot Add را برای همان ماشین بررسی کنید. پیش از برنامه‌ریزی ارتقا، سازگاری سیستم‌عامل و سناریوی خود را بررسی کنید. اگر برنامه و پایگاه داده را روی چند ماشین جدا اجرا می‌کنید، در ابر خصوصی ابر آراد می‌توان منابع محیط را متناسب با نیاز میان ماشین‌ها تخصیص داد؛ این قابلیت جای تخمین و آزمون هر ماشین را نمی‌گیرد.
برای تعیین منابع مورد نیاز سرور مجازی، فهرست سرویس‌ها، مصرف زمان اوج بار و نتیجهٔ آزمون را ثبت کنید. سپس پلن‌های سرور مجازی ابر آراد را بر همین مبنا بررسی کنید. سپس هزینه و شرایط نگهداری را با چک‌لیست خرید سرور مجازی تطبیق دهید تا تصمیم فنی و بودجه پروژه با هم هماهنگ باشند.
از صفحه تماس ابر آراد، مسیر ارتباط با تیم را انتخاب کنید.
دیدگاه‌ها و پرسش‌های شما
تجربه یا پرسش خود را درباره موضوع مقاله با ما در میان بگذارید.
هنوز دیدگاهی ثبت نشده است؛ شما گفت‌وگو را شروع کنید.