هسته مجازی یا vCPU چیست؟ تفاوت آن با هسته فیزیکی و ترد

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

هسته مجازی یا vCPU دقیقاً چیست؟

پردازنده فیزیکی در سرور میزبان قرار دارد و منابع آن می‌تواند میان چند ماشین مجازی تقسیم شود. هایپروایزر برای هر ماشین تعدادی پردازنده مجازی تعریف می‌کند؛ سیستم‌عامل مهمان این پردازنده‌ها را به شکل CPUهای قابل استفاده می‌بیند، اما اجرای دستورها در نهایت روی هسته‌ها و تردهای واقعی میزبان انجام می‌شود.

در بسیاری از محیط‌های مجازی‌سازی، هر vCPU به یک ترد اجرایی در میزبان مربوط است. به همین دلیل، تعداد vCPU با تعداد هسته فیزیکی برابر نیست. اگر پردازنده از Hyper-Threading یا SMT پشتیبانی کند، هر هسته فیزیکی می‌تواند بیش از یک ترد منطقی در اختیار زمان‌بند قرار دهد. دو ترد منطقی همچنان منابع اجرایی یک هسته فیزیکی را به اشتراک می‌گذارند.

چرا سیستم‌عامل مهمان تفاوت را به‌سادگی نمی‌بیند؟

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

تفاوت سوکت، هسته فیزیکی، ترد و vCPU

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

• سوکت: جایگاه فیزیکی پردازنده روی مادربرد سرور.
• هسته فیزیکی: واحد پردازشی واقعی داخل تراشه.
• ترد منطقی: مسیر اجرایی‌ای که فناوری SMT یا Hyper-Threading در اختیار سیستم‌عامل می‌گذارد.
• vCPU: پردازنده مجازی تعریف‌شده برای ماشین مهمان که زمان اجرای آن روی میزبان تخصیص داده می‌شود.

برای نمونه، اگر یک پردازنده ۸ هسته فیزیکی داشته باشد و هر هسته دو ترد منطقی ارائه کند، سیستم میزبان ممکن است ۱۶ پردازنده منطقی را ببیند. این مثال به معنای دو برابر شدن توان پردازنده نیست؛ فقط تعداد مسیرهای زمان‌بندی بیشتر شده است. عملکرد واقعی به نوع بار، معماری پردازنده و میزان اشتراک منابع بستگی دارد.

Hyper-Threading چرا دو برابر توان ایجاد نمی‌کند؟

Hyper-Threading در پردازنده‌های اینتل و فناوری SMT در معماری‌های دیگر اجازه می‌دهند بیش از یک ترد روی یک هسته فیزیکی زمان‌بندی شود. هدف این است که وقتی یک ترد منتظر داده یا منبعی است، ترد دیگر بتواند از بخشی از واحدهای اجرایی بلااستفاده استفاده کند. در نتیجه، بهره‌برداری از هسته بهتر می‌شود؛ اما دو ترد همچنان کش و بخش‌هایی از منابع اجرایی همان هسته را شریک هستند.

به همین علت، دو vCPU که روی دو ترد یک هسته فیزیکی قرار گرفته‌اند، معادل دو هسته مستقل نیستند. میزان سود SMT به نوع برنامه وابسته است. بارهایی که زمان زیادی را منتظر I/O می‌مانند ممکن است از هم‌زمانی بیشتر سود ببرند، اما کار محاسباتی پیوسته که همه واحدهای اجرایی را درگیر می‌کند، معمولاً سود کمتری می‌گیرد.

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

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

بنابراین صرفاً از روی تعداد vCPU نمی‌توان گفت یک پلن برای برنامه شما سریع است. باید نوع کار، میزان موازی‌سازی و رفتار آن در ساعت اوج را بسنجید.

اورکامیت پردازنده و مفهوم سهم واقعی منابع

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

از سوی دیگر، مدیر میزبان می‌تواند برای هر ماشین محدودیت یا وزن زمان‌بندی تعیین کند. در محیط Proxmox، گزینه‌هایی مانند cpulimit و cpuunits برای کنترل سقف و وزن نسبی پردازنده به کار می‌روند. cpulimit می‌تواند مجموع زمان CPU ماشین را محدود کند؛ cpuunits وزن نسبی آن را در رقابت با ماشین‌های دیگر تعیین می‌کند. این تنظیم‌ها معمولاً از داخل سیستم‌عامل مهمان قابل مشاهده یا تغییر نیستند.

Steal Time چه چیزی را نشان می‌دهد؟

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

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

برای سایت، دیتابیس و ویندوز چند vCPU لازم است؟

تعداد مناسب پردازنده مجازی را باید از بار کاری شروع کرد، نه از اندازه فایل‌ها یا تعداد کاربران ثبت‌نام‌شده. برای یک وب‌سایت ساده، دو vCPU می‌تواند نقطه شروع قابل بررسی باشد. فروشگاه پرترافیک، برنامه چندسرویسی یا دیتابیس سنگین ممکن است به منابع بیشتری نیاز داشته باشد؛ اما ارتقا باید با اندازه‌گیری CPU، RAM، I/O و تعداد رشته‌های فعال توجیه شود.

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

چطور اطلاعات CPU و رفتار vCPU را روی لینوکس بررسی کنیم؟

چند دستور فقط‌خواندنی می‌تواند تصویر اولیه‌ای از پردازنده‌ای که سیستم‌عامل مهمان می‌بیند ارائه کند. خروجی lscpu اطلاعاتی مانند معماری، تعداد CPUهای قابل مشاهده، سوکت، هسته و ترد را نشان می‌دهد. دستور nproc تعداد پردازنده‌های در دسترس فرایند جاری را گزارش می‌کند؛ گزینه –all برای دیدن تعداد کل CPUهای قابل مشاهده کاربرد دارد.

برای بررسی رفتار واقعی، به یک بار کاری مشخص نیاز دارید. سنگین‌ترین درخواست سایت یا کوئری پرتکرار دیتابیس را در شرایط کنترل‌شده اجرا کنید، زمان پاسخ را چند بار ثبت کنید و میانه نتایج را به دست آورید. هم‌زمان top یا ابزار پایش را باز نگه دارید تا مصرف CPU و مقدار st را ببینید.

• با lscpu توپولوژی CPU قابل مشاهده در ماشین را بررسی کنید.
• با nproc –all تعداد پردازنده‌های قابل مشاهده را ببینید.
• با top -H یا ps -eLf تعداد تردهای فعال برنامه را بررسی کنید.
• در ساعت اوج، مقدار st را ثبت کنید و آن را با زمان خلوت مقایسه کنید.
• یک عملیات واقعی برنامه را چند بار اجرا کنید و میانه زمان را مبنای مقایسه قرار دهید.

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

پرسش‌های متداول درباره vCPU

آیا دو vCPU برابر دو هسته فیزیکی است؟

خیر. هر vCPU می‌تواند به یک ترد منطقی میزبان مربوط باشد. اگر دو ترد روی یک هسته فیزیکی باشند، منابع آن هسته را شریک می‌شوند و عملکردشان معادل دو هسته مستقل نیست.

آیا lscpu اختصاصی بودن هسته را ثابت می‌کند؟

خیر. این ابزار اطلاعاتی را نمایش می‌دهد که محیط سیستم‌عامل در اختیارش گذاشته است. در ماشین مجازی، توپولوژی نمایش‌داده‌شده ممکن است با سخت‌افزار فیزیکی میزبان تفاوت داشته باشد.

آیا اورکامیت همیشه بد است؟

نه. تخصیص بیش از ظرفیت فیزیکی در محیط‌های مجازی رایج است و زمانی مسئله‌ساز می‌شود که رقابت ماشین‌ها باعث انتظار پایدار برای پردازنده شود. مقدار steal و عملکرد واقعی را در ساعت‌های مختلف بسنجید.

برای وردپرس معمولی چند هسته لازم است؟

برای شروع، یک یا دو vCPU می‌تواند کافی باشد؛ فروشگاه، افزونه‌های سنگین یا ترافیک هم‌زمان ممکن است منابع بیشتری بخواهد. تصمیم را با پایش مصرف و آزمون بار واقعی بگیرید.

چرا با افزایش vCPU سرعت بهتر نشد؟

ممکن است برنامه تک‌تردی باشد، گلوگاه در دیسک یا پایگاه داده قرار داشته باشد، یا سهم پردازنده میزبان محدود باشد. مصرف CPU، I/O و steal را هم‌زمان بررسی کنید.

جمع‌بندی؛ تعداد vCPU را با عملکرد واقعی بسنجید

vCPU یک پردازنده فیزیکی جداگانه نیست؛ واحد پردازشی مجازی‌ای است که هایپروایزر زمان اجرای آن را روی منابع میزبان مدیریت می‌کند. Hyper-Threading یا SMT تعداد تردهای قابل زمان‌بندی را افزایش می‌دهد، اما دو ترد روی یک هسته فیزیکی معادل دو هسته مستقل نیستند. برای انتخاب پلن، تعداد vCPU را در کنار نسل و فرکانس پردازنده، نوع بار، محدودیت‌های میزبان و مقدار Steal Time ارزیابی کنید. در نهایت، یک آزمون از بار واقعی برنامه شما از مقایسه صرف اعداد پنل یا تعداد هسته‌ها تصمیم دقیق‌تری می‌سازد.

چرا تعداد vCPU به‌تنهایی معیار کیفیت پلن نیست؟

دو پلن با تعداد vCPU یکسان ممکن است عملکرد متفاوتی داشته باشند. نسل پردازنده، فرکانس، اندازه کش، معماری و نوع دستورهای پشتیبانی‌شده بر میزان کاری که هر ترد در یک ثانیه انجام می‌دهد اثر می‌گذارند. علاوه بر این، سهم زمانی که هایپروایزر در ساعت اوج در اختیار ماشین می‌گذارد نیز مهم است.

به همین دلیل، هنگام مقایسه دو پلن فقط به تعداد هسته نگاه نکنید. مدل پردازنده میزبان و شرایط تخصیص منابع را از ارائه‌دهنده بپرسید و در صورت امکان، یک بار کاری واقعی روی هر دو اجرا کنید. امتیاز بنچمارک تک‌هسته می‌تواند برای مقایسه اولیه مفید باشد، اما باید در کنار Steal Time و عملکرد دیسک دیده شود.

مدل CPU که مهمان می‌بیند لزوماً مدل میزبان نیست

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

سطح‌های قابلیت پردازنده x86-64 نیز یکسان نیستند. برخی سطح‌ها مجموعه دستورهای بیشتری مانند SSE4، AVX، AVX2 یا AVX-512 را در اختیار نرم‌افزار می‌گذارند. برنامه‌هایی که برای این دستورها بهینه شده‌اند ممکن است از قابلیت‌های تازه‌تر سود ببرند، اما استفاده واقعی به نرم‌افزار و معماری میزبان وابسته است.

چطور تعداد هسته موردنیاز را تخمین بزنیم؟

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

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

تست عملی به جای حدس

1. یک عملیات سنگین و تکرارپذیر از برنامه انتخاب کنید؛ مانند درخواست پرترافیک یا کوئری مشخص.
2. زمان اجرای آن را چند بار ثبت و میانه را محاسبه کنید.
3. در همان بازه، مصرف CPU، تعداد تردها و مقدار Steal را بررسی کنید.
4. اگر امکان دارد، آزمایش را با منابع متفاوت و شرایط مشابه تکرار کنید.
5. فقط زمانی منابع را افزایش دهید که داده‌ها نشان دهند پردازنده عامل محدودکننده است.

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

محدودیت‌های پردازنده مجازی را از کجا بشناسیم؟

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

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

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

ارتقای منابع را مرحله‌ای انجام دهید

اگر سرور کند شده، قبل از ارتقای CPU نمودار مصرف RAM، Swap، I/O و بار پردازنده را بررسی کنید. پر شدن حافظه می‌تواند باعث جابه‌جایی داده به Swap شود و تأخیر زیادی ایجاد کند. همچنین کوئری بدون ایندکس یا ذخیره‌ساز کند می‌تواند برنامه را متوقف کند، حتی اگر چند vCPU آزاد در اختیار داشته باشید.

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

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

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

اگر تغییر تعداد پردازنده یا محدودیت منابع نیازمند راه‌اندازی مجدد است، زمان آن را از قبل با برنامه کاری سرویس هماهنگ کنید.