که تاسو د VMware vSphere (یا کوم بل ټیکنالوژۍ سټیک) پراساس مجازی زیربنا اداره کوئ ، نو تاسو شاید ډیری وختونه د کاروونکو شکایتونه واورئ: "مجازی ماشین ورو دی!" د مقالو پدې لړۍ کې به زه د فعالیت میټریکونه تحلیل کړم او تاسو ته به ووایم چې څه او ولې دا ورو کیږي او څنګه ډاډ ترلاسه کړئ چې دا ورو نه کیږي.
زه به د مجازی ماشین فعالیت لاندې اړخونه په پام کې ونیسم:
- سي پي يو ،
- فريم ،
- ډیسک،
- شبکه.
زه به د CPU سره پیل کړم.
د فعالیت تحلیل لپاره موږ اړتیا لرو:
- د vCenter فعالیت شمیرونکي - د فعالیت شمیرونکي، ګرافونه چې د vSphere پیرودونکي له لارې لیدل کیدی شي. د دې کاونټرونو په اړه معلومات د مراجعینو په هره نسخه کې شتون لري (په C# کې "موټی" مراجع، په فلیکس کې ویب مراجع او په HTML5 کې ویب مراجع). پدې مقالو کې به موږ د C# پیرودونکي څخه سکرین شاټونه وکاروو ، یوازې دا چې دوی په کوچني کې غوره ښکاري :)
- ESXTOP - یو اسانتیا چې د ESXi کمانډ لاین څخه تیریږي. د دې په مرسته، تاسو کولی شئ په ریښتیني وخت کې د فعالیت شمیرونکي ارزښتونه ترلاسه کړئ یا دا ارزښتونه د یوې ټاکلې مودې لپاره د نورو تحلیلونو لپاره په .csv فایل کې اپلوډ کړئ. بل ، زه به تاسو ته د دې وسیلې په اړه نور معلومات درکړم او په موضوع کې د اسنادو او مقالو لپاره ډیری ګټور لینکونه چمتو کړم.
یو څه تیوری
په ESXi کې، یو جلا بهیر - د VMware په اصطلاح کې نړۍ - د هر vCPU (مجازی ماشین کور) د عملیاتو مسولیت لري. د خدماتو پروسې هم شتون لري ، مګر د VM فعالیت تحلیل کولو له نظره دوی لږ په زړه پوري دي.
په ESXi کې پروسه له څلورو حالتونو څخه یوه کې کیدی شي:
- د دويم - پروسه یو څه ګټور کار ترسره کوي.
- انتظار - پروسه هیڅ کار نه کوي (بې کاره) یا د ننوتلو/آؤټ پوټ لپاره انتظار باسي.
- کوسټاپ - یو حالت چې په ملټي کور مجازی ماشینونو کې پیښیږي. دا واقع کیږي کله چې د هایپروایسر CPU شیډولر (ESXi CPU شیډولر) نشي کولی د فزیکي سرور کورونو کې د ټولو فعال مجازی ماشین کورونو یوځل اجرا کولو مهالویش وکړي. په فزیکي نړۍ کې، ټول پروسیسر کورونه په موازي توګه کار کوي، د VM دننه میلمانه OS د ورته چلند تمه لري، نو هایپروایزر باید د VM کور ورو کړي چې د دوی د ساعت دورې ګړندي پای ته رسولو وړتیا لري. د ESXi په عصري نسخو کې، د CPU مهالویش کونکی یو میکانیزم کاروي چې د آرامۍ شریک مهالویش په نوم یادیږي: هایپروایسر د "ترټولو" او "ورو" مجازی ماشین کور (سکیو) تر مینځ واټن په پام کې نیسي. که چیرې تشه له یو ټاکلي حد څخه زیاته وي، چټک کور د کوسټاپ حالت ته ننوځي. که د VM کورونه پدې حالت کې ډیر وخت تیر کړي ، نو دا کولی شي د فعالیت مسلو لامل شي.
- چمتو - پروسه دې حالت ته ننوځي کله چې هایپروایزر نشي کولی د دې اجرا کولو لپاره سرچینې تخصیص کړي. لوړ چمتو شوي ارزښتونه کولی شي د VM فعالیت ستونزې رامینځته کړي.
د اصلي مجازی ماشین CPU فعالیت کاونټرونه
د CPU کارول،٪. د یوې ټاکلې مودې لپاره د CPU کارونې سلنه ښیې.
څنګه تحلیل کړو؟ که یو VM په دوامداره توګه CPU په 90٪ کې کاروي یا تر 100٪ پورې لوړوالی شتون لري، نو موږ ستونزې لرو. ستونزې نه یوازې د VM دننه د غوښتنلیک "ورو" عملیاتو کې څرګند کیدی شي ، بلکه په شبکه کې د VM لاسرسي کې هم. که چیرې د څارنې سیسټم وښيي چې VM په دوره توګه راټیټیږي، د CPU کارولو ګراف کې لوړوالی ته پام وکړئ.
دلته یو معیاري الارم شتون لري چې د مجازی ماشین CPU بار ښیې:
زه باید څه وکړم؟ که چیرې د VM CPU کارول په دوامداره توګه د چت څخه تیریږي ، نو تاسو کولی شئ د vCPUs شمیر زیاتولو په اړه فکر وکړئ (له بده مرغه ، دا تل مرسته نه کوي) یا VM د ډیر ځواکمن پروسیسرونو سره سرور ته لیږدول.
په MHz کې د CPU کارول
په ګرافونو کې د vCenter کارول په٪ کې تاسو یوازې د ټول مجازی ماشین لپاره لیدلی شئ؛ د انفرادي کور لپاره هیڅ ګراف شتون نلري (په Esxtop کې د کور لپاره٪ ارزښتونه شتون لري). د هر کور لپاره تاسو کولی شئ په MHz کې کارول وګورئ.
څنګه تحلیل کړو؟ داسې پیښیږي چې یو غوښتنلیک د څو کور جوړښت لپاره مطلوب ندی: دا یوازې یو کور 100٪ کاروي، او پاتې نور پرته له بار څخه بې کاره دي. د مثال په توګه، د ډیفالټ بیک اپ ترتیباتو سره، MS SQL پروسه یوازې په یوه کور پیل کوي. د پایلې په توګه ، بیک اپ د ډیسکونو ورو سرعت له امله نه سست کیږي (دا هغه څه دي چې کارونکي یې په پیل کې شکایت کړی و) ، مګر دا چې پروسیسر نشي کولی مقابله وکړي. ستونزه د پیرامیټونو په بدلولو سره حل شوې: بیک اپ په موازي ډول په څو فایلونو کې پیل شو (په ترتیب سره ، په څو پروسو کې).
په کور کې د غیر مساوي بار یوه بیلګه.
یو حالت هم شتون لري (لکه څنګه چې پورته ګراف کې) کله چې کورونه په غیر مساوي ډول بار شوي او ځینې یې د 100٪ لوړوالی لري. لکه څنګه چې یوازې د یو کور بار کولو سره ، د CPU کارولو لپاره الارم به کار ونکړي (دا د ټول VM لپاره دی) ، مګر د فعالیت ستونزې به وي.
زه باید څه وکړم؟ که چیرې په مجازی ماشین کې سافټویر کورونه په غیر مساوي ډول بار کړي (یوازې یو کور یا د کور برخه کاروي) ، د دوی شمیر زیاتولو کې هیڅ معنی نشته. په دې حالت کې، دا غوره ده چې VM د ډیر پیاوړي پروسیسرونو سره سرور ته انتقال کړئ.
تاسو کولی شئ په سرور BIOS کې د بریښنا مصرف تنظیمات چیک کولو هڅه هم وکړئ. ډیری مدیران په BIOS کې د لوړ فعالیت حالت فعالوي او پدې توګه د C-States او P-States د انرژي سپمولو ټیکنالوژي غیر فعالوي. عصري Intel پروسیسرونه د ټربو بوسټ ټیکنالوژي کاروي، کوم چې د نورو کورونو په لګښت د انفرادي پروسیسر کور فریکوینسي زیاتوي. مګر دا یوازې هغه وخت کار کوي کله چې د انرژي سپمولو ټیکنالوژي فعاله وي. که موږ دوی غیر فعال کړو، پروسیسر نشي کولی د کور د بریښنا مصرف کم کړي چې بار شوي ندي.
VMware وړاندیز کوي چې په سرورونو کې د بریښنا سپمولو ټیکنالوژۍ غیر فعال نه کړي، مګر هغه طریقې غوره کړي چې د بریښنا مدیریت د امکان تر حده هایپروایزر ته پریږدي. پدې حالت کې ، د هایپروایزر بریښنا مصرف تنظیماتو کې ، تاسو اړتیا لرئ د لوړ فعالیت غوره کړئ.
که تاسو په خپل زیربنا کې انفرادي VMs (یا VM کورونه) لرئ چې د CPU فریکوینسي زیاتوالي ته اړتیا لري ، د بریښنا مصرف په سمه توګه تنظیم کول کولی شي د پام وړ فعالیت ښه کړي.
CPU چمتو دی
که د VM کور (vCPU) په چمتو حالت کې وي، دا ګټور کار نه کوي. دا حالت هغه وخت رامینځته کیږي کله چې هایپروایزر وړیا فزیکي کور ونه موندل شي کوم چې د مجازی ماشین vCPU پروسه ټاکل کیدی شي.
څنګه تحلیل کړو؟ عموما، که د مجازی ماشین کورونه د 10٪ څخه ډیر وخت په چمتو حالت کې وي، تاسو به د فعالیت مسلې وګورئ. په ساده ډول ووایاست، د 10٪ څخه ډیر وخت VM د فزیکي سرچینو شتون ته انتظار کوي.
په vCenter کې تاسو کولی شئ د CPU چمتو پورې اړوند 2 کاونټرونه وګورئ:
- چمتووالی
- چمتو دی.
د دواړو کاونټرونو ارزښتونه د ټول VM او انفرادي کور لپاره دواړه لیدل کیدی شي.
چمتووالی سمدلاسه د فیصدي په توګه ارزښت ښیې ، مګر یوازې په ریښتیني وخت کې (د وروستي ساعت ډاټا ، د اندازه کولو وقفه 20 ثانیې). دا غوره ده چې دا کاونټر یوازې د ستونزو د لټون لپاره وکاروئ "په پښو ګرم".
چمتو ضد ارزښتونه هم د تاریخي لید څخه لیدل کیدی شي. دا د نمونو رامینځته کولو او د ستونزې ژور تحلیل لپاره ګټور دی. د مثال په توګه ، که چیرې یو مجازی ماشین په یو ټاکلي وخت کې د فعالیت ستونزې تجربه کول پیل کړي ، تاسو کولی شئ د CPU چمتو ارزښت وقفې په سرور کې د ټول بار سره پرتله کړئ چیرې چې دا VM چلیږي ، او د بار کمولو لپاره اقدامات وکړئ (که DRS ناکامیږي).
چمتو، د چمتووالي برعکس، په فیصدو کې نه ښودل کیږي، مګر په ملی ثانیو کې. دا د سمیشن ډول کاونټر دی ، دا دا ښیې چې د اندازه کولو دورې په جریان کې د VM کور څومره وخت په چمتو حالت کې و. تاسو کولی شئ دا ارزښت د ساده فورمول په کارولو سره په سلنه کې بدل کړئ:
(د CPU چمتو شوي مجموعه ارزښت / (د چارټ ډیفالټ تازه وقفه په ثانیو کې * 1000)) * 100 = CPU چمتو٪
د مثال په توګه، په لاندې ګراف کې د VM لپاره، د ټول مجازی ماشین لپاره د لوړ چمتو ارزښت به په لاندې ډول وي:
کله چې د چمتو شوي فیصده محاسبه کول، تاسو باید دوه ټکو ته پام وکړئ:
- د ټول VM لپاره چمتو ارزښت د کور په اوږدو کې د چمتو مجموعه ده.
- د اندازه کولو وقفه. د ریښتیني وخت لپاره دا 20 ثانیې دي ، او د مثال په توګه ، په ورځني چارټونو کې دا 300 ثانیې دي.
د فعالې ستونزې حل کولو سره، دا ساده ټکي په اسانۍ سره له لاسه ورکول کیدی شي او د غیر موجود ستونزو په حل کولو کې ارزښتناکه وخت ضایع کیدی شي.
راځئ چې د لاندې ګراف څخه د معلوماتو پراساس چمتو محاسبه کړو. (324474/(20*1000))*100 = 1622% د ټول VM لپاره. که تاسو کورونو ته وګورئ دا دومره ویره نلري: 1622/64 = په هر کور کې 25٪. په دې حالت کې، کیچ د موندلو لپاره خورا اسانه دی: د چمتو شوي ارزښت غیر واقعیت دی. مګر که موږ د څو کورونو سره د ټول VM لپاره د 10-20٪ په اړه وغږیږو ، نو د هر کور لپاره ارزښت ممکن په نورمال حد کې وي.
زه باید څه وکړم؟ یو لوړ چمتو ارزښت په ګوته کوي چې سرور د مجازی ماشینونو نورمال عملیاتو لپاره کافي پروسیسر سرچینې نلري. په داسې حالت کې، ټول هغه څه چې پاتې دي د پروسیسر (vCPU: pCPU) لخوا د ګډون کمول دي. په ښکاره ډول، دا د موجوده VMs پیرامیټونو کمولو یا نورو سرورونو ته د VMs برخې لیږدولو سره ترلاسه کیدی شي.
شریک ودرول
څنګه تحلیل کړو؟ دا کاونټر هم د مجموعې ډول دی او په سلو کې په ورته ډول بدلیږي لکه چمتو:
(د CPU شریک تمځای ارزښت / (د چارټ ډیفالټ تازه وقفه په ثانیو کې * 1000)) * 100 = د CPU شریک تمځای٪
دلته تاسو اړتیا لرئ په VM کې د کور شمیر او د اندازه کولو وقفې ته هم پاملرنه وکړئ.
د کوسټاپ حالت کې، دانه ګټور کار نه کوي. په سرور کې د VM اندازې او نورمال بار سم انتخاب سره ، د کوسټ سټاپ کاونټر باید صفر ته نږدې وي.
په دې حالت کې، بار په واضح ډول غیر معمولي دی :)
زه باید څه وکړم؟ که چیرې څو VMs د لوی شمیر کورونو سره په یو هایپروایسر کې روان وي او په CPU کې نظارت شتون ولري ، نو د شریک سټاپ کاونټر ممکن ډیر شي ، کوم چې به د دې VMs فعالیت سره ستونزې رامینځته کړي.
همچنان ، شریک تمځای به ډیر شي که چیرې د یو VM فعال کور د هایپر ټریډینګ فعال شوي سره په یو فزیکي سرور کور کې تارونه کاروي. دا وضعیت ممکن رامینځته شي ، د مثال په توګه ، که چیرې VM په سرور کې د فزیکي پلوه شتون څخه ډیر کورونه ولري چیرې چې دا چلیږي ، یا که د VM لپاره د "preferHT" ترتیب فعال شوی وي. تاسو کولی شئ د دې ترتیب په اړه ولولئ .
د لوړ شریک سټاپ له امله د VM فعالیت سره د ستونزو مخنیوي لپاره ، د VM اندازه د سافټویر جوړونکي وړاندیزونو سره سم غوره کړئ چې پدې VM کې چلیږي او د فزیکي سرور وړتیاو سره چیرې چې VM چلیږي.
په ریزرو کې کورونه مه اضافه کړئ؛ دا ممکن نه یوازې د VM لپاره د فعالیت ستونزې رامینځته کړي ، بلکه په سرور کې د دې ګاونډیانو لپاره هم.
نور ګټور CPU میټریکونه
د دويم - څومره وخت (ms) د اندازه کولو دورې په جریان کې vCPU په RUN حالت کې و ، دا واقعیا ګټور کار ترسره کوي.
idle - څومره وخت (ms) د اندازه کولو دورې په جریان کې vCPU په غیر فعال حالت کې و. لوړ غیر فعال ارزښتونه کومه ستونزه نده ، vCPU یوازې "هیڅ شی نه درلود."
انتظار - څومره وخت (ms) د اندازه کولو دورې په جریان کې vCPU د انتظار حالت کې و. څرنګه چې IDLE پدې کاونټر کې شامل دی ، د لوړ انتظار ارزښتونه هم ستونزه نه په ګوته کوي. مګر که د انتظار IDLE ټیټ وي کله چې انتظار لوړ وي ، نو دا پدې معنی ده چې VM د I/O عملیاتو بشپړیدو ته انتظار باسي ، او دا په پایله کې ممکن د هارډ ډرایو یا د VM کوم مجازی وسیلو فعالیت کې ستونزه په ګوته کړي.
اعظمي محدود - څومره وخت (ms) د اندازه کولو دورې په جریان کې vCPU په چمتو حالت کې د سرچینې ټاکل شوي حد له امله. که فعالیت په غیر معقول ډول ټیټ وي ، نو دا ګټوره ده چې د دې کاونټر ارزښت او د VM تنظیماتو کې د CPU حد چیک کړئ. VMs ممکن واقعیا محدودیتونه ولري چې تاسو یې نه خبر یاست. د مثال په توګه، دا پیښیږي کله چې VM د یوې ټیمپلیټ څخه کلون شوی و چې د CPU حد ټاکل شوی و.
انتظار بدل کړئ - د اندازه کولو مودې په جریان کې څومره وخت vCPU د VMkernel سویپ سره عملیاتو ته انتظار باسي. که د دې کاونټر ارزښتونه له صفر څخه پورته وي ، نو بیا VM یقینا د فعالیت ستونزې لري. موږ به د RAM کاونټرونو په اړه مقاله کې د SWAP په اړه نور خبرې وکړو.
ESXTOP
که په vCenter کې د فعالیت شمیرونکي د تاریخي معلوماتو تحلیل لپاره ښه وي، نو د ستونزې عملیاتي تحلیل په ESXTOP کې ښه ترسره کیږي. دلته، ټول ارزښتونه په چمتو شوي بڼه کې وړاندې شوي (د هیڅ شی ژباړلو ته اړتیا نشته)، او د اندازه کولو لږترلږه موده 2 ثانیې ده.
د CPU لپاره د ESXTOP سکرین د "c" کیلي سره ویل کیږي او داسې ښکاري:
د اسانتیا لپاره، تاسو کولی شئ د Shift-V په فشارولو سره یوازې د مجازی ماشین پروسې پریږدئ.
د انفرادي VM کور لپاره میټریکونو لیدو لپاره ، "e" فشار ورکړئ او د ګټو VM GID دننه کړئ (په لاندې سکرین شاټ کې 30919):
اجازه راکړئ په لنډ ډول د کالمونو له لارې لاړ شم چې د ډیفالټ لخوا وړاندې کیږي. اضافي کالمونه د "f" په فشارولو سره اضافه کیدی شي.
NWLD (د نړۍ شمیر) - په ګروپ کې د پروسو شمیر. د ګروپ پراخولو لپاره او د هرې پروسې لپاره میټریک وګورئ (د مثال په توګه، په څو کور VM کې د هر کور لپاره)، "e" فشار ورکړئ. که چیرې په یوه ګروپ کې له یو څخه ډیر پروسې شتون ولري، نو د ګروپ لپاره میټریک ارزښتونه د انفرادي پروسو لپاره د میټریکونو مجموعې سره مساوي دي.
کارول شوي - څومره سرور CPU دورې د پروسې یا پروسې ګروپ لخوا کارول کیږي.
چلول - د اندازه کولو دورې په جریان کې څومره وخت پروسه په RUN حالت کې وه، د بیلګې په توګه. ګټور کار وکړ. دا د %USED څخه په دې کې توپیر لري چې دا د هایپر-تریډینګ، فریکونسۍ اندازه کول او د سیسټم په کارونو کې مصرف شوي وخت (%SYS) په پام کې نه نیسي.
SYS - د سیسټم په دندو کې مصرف شوي وخت، د بیلګې په توګه: د پروسس کولو خنډ، I/O، د شبکې عملیات، او نور. ارزښت کیدای شي لوړ وي که چیرې VM لوی I/O ولري.
OVRLP - څومره وخت چې فزیکي کور په کوم کې چې د VM پروسه روانه ده د نورو پروسو په کارونو کې مصرفوي.
دا معیارونه یو له بل سره په لاندې ډول تړاو لري:
%استعمال =%RUN +%SYS -%OVRLP.
عموما د % USED میټریک ډیر معلوماتی دی.
انتظار وکړئ - د اندازه کولو دورې په جریان کې پروسه څومره وخت په انتظار حالت کې وه. IDLE فعالوي.
% IDLE - د اندازه کولو دورې په جریان کې پروسه په IDLE حالت کې څومره وه.
%SWPWT - د اندازه کولو مودې په جریان کې څومره وخت vCPU د VMkernel سویپ سره عملیاتو ته انتظار باسي.
VMWAIT - د اندازه کولو دورې په جریان کې څومره وخت vCPU د پیښې لپاره د انتظار په حالت کې و (معمولا I/O). په vCenter کې ورته کاونټر نشته. لوړ ارزښتونه په VM کې د I/O سره ستونزې په ګوته کوي.
% WAIT = % VMWAIT + % IDLE + % SWPWT.
که VM د VMkernel سویپ نه کاروي، نو کله چې د فعالیت ستونزې تحلیل کوي نو دا مشوره ورکول کیږي چې % VMWAIT وګورئ، ځکه چې دا میټریک هغه وخت په پام کې نه نیسي کله چې VM هیڅ نه کوي (٪ IDLE).
%RDY - د اندازه کولو دورې په جریان کې څومره وخت پروسه په چمتو حالت کې وه.
%CSTP - د اندازه کولو دورې په جریان کې پروسه څومره وخت په کوسټاپ حالت کې وه.
%MLMTD - د اندازه کولو مودې په جریان کې vCPU د ټاکل شوي سرچینې حد له امله په چمتو حالت کې و.
% WAIT + % RDY + % CSTP + % RUN = 100٪ - د VM کور تل له دې څلورو ایالتونو څخه یو کې وي.
CPU په هایپروایسر کې
vCenter د هایپروایزر لپاره د CPU فعالیت کاونټرونه هم لري ، مګر دا په زړه پوري ندي - دا په ساده ډول په سرور کې د ټولو VMs لپاره د کاونټرونو مجموعه ده.
په سرور کې د CPU حالت لیدو ترټولو اسانه لار د لنډیز ټب کې ده:
د سرور لپاره، او همدارنګه د مجازی ماشین لپاره، یو معیاري الارم شتون لري:
کله چې د سرور CPU بار لوړ وي، VMs چې پدې کې روان وي د فعالیت ستونزې تجربه کول پیل کوي.
په ESXTOP کې، د سرور CPU بار ډیټا د سکرین په پورتنۍ برخه کې وړاندې کیږي. د معیاري CPU بار سربیره ، کوم چې د هایپروایزرونو لپاره خورا معلوماتي ندي ، درې نور میټریکونه شتون لري:
کور یوټیل (٪) - د فزیکي سرور کور بار کول. دا کاونټر ښیې چې د اندازه کولو دورې په جریان کې کور څومره وخت کار کړی.
PCPU UTIL(%) - که چیرې هایپر-تریډینګ فعال شوی وي ، نو په هر فزیکي کور کې دوه تارونه (PCPU) شتون لري. دا میټریک ښیې چې هر تار د کار بشپړولو لپاره څومره وخت نیولی.
PCPU کارول شوی (%) - د PCPU UTIL(%) په څیر، مګر د فریکونسۍ اندازه کول په پام کې نیسي (یا د انرژي سپمولو موخو لپاره د اصلي فریکونسۍ کمول، یا د ټربو بوسټ ټیکنالوژۍ له امله د اصلي فریکونسۍ زیاتوالی) او هایپر-تریډینګ.
PCPU_USED٪ = PCPU_UTIL٪ * اغیزمن کور فریکونسۍ / نومول اصلي فریکونسۍ.
په دې سکرین شاټ کې، د ځینو کورونو لپاره، د ټربو بوسټ له امله، د USED ارزښت له 100٪ څخه ډیر دی، ځکه چې اصلي فریکونسۍ د نومول شوي څخه لوړه ده.
د هایپر-تریډینګ څرنګوالي په اړه یو څو ټکي په پام کې نیول شوي. که چیرې پروسې د سرور فزیکي کور په دواړو تارونو کې 100٪ وخت اجرا شي، پداسې حال کې چې کور په نامتو فریکونسۍ کې کار کوي، بیا:
- د کور لپاره CORE UTIL به 100٪ وي،
- د دواړو تارونو لپاره PCPU UTIL به 100٪ وي،
- د دواړو تارونو لپاره کارول شوی PCPU به 50٪ وي.
که دواړه تارونه د اندازه کولو دورې په جریان کې 100٪ کار نه کوي، نو د دې مودې په جریان کې کله چې تارونه په موازي توګه کار کوي، د PCPU کارول د کور لپاره په نیمایي ویشل شوي.
ESXTOP د سرور CPU بریښنا مصرف پیرامیټونو سره سکرین هم لري. دلته تاسو لیدلی شئ چې ایا سرور د انرژي سپمولو ټیکنالوژي کاروي: C-States او P-states. د "p" کیلي سره ویل کیږي:
د CPU فعالیت عام مسلې
په نهایت کې ، زه به د VM CPU فعالیت سره د ستونزو عادي لاملونو ته لاړ شم او د دوی د حل لپاره به لنډ لارښوونې ورکړم:
د اصلي ساعت سرعت کافي ندي. که چیرې دا ممکنه نه وي چې خپل VM ډیر پیاوړي کور ته لوړ کړئ، تاسو کولی شئ د بریښنا ترتیباتو بدلولو هڅه وکړئ ترڅو د ټربو بوسټ کار ډیر اغیزمن کړي.
د VM ناسم اندازه کول (ډیری / څو کورونه). که تاسو یو څو کورونه نصب کړئ ، نو په VM کې به د CPU لوړ بار وي. که چیرې ډیر وي، یو لوړ کوډ سټاپ ونیسئ.
په سرور کې د CPU لوی ګډون. که چیرې VM لوړ چمتو وي، د CPU ګډون کم کړئ.
په لویو VMs کې ناسم NUMA ټوپولوژي. د VM (vNUMA) لخوا لیدل شوي NUMA ټوپولوژي باید د سرور (pNUMA) د NUMA ټوپولوژي سره سمون ولري. د دې ستونزې تشخیص او ممکنه حلونه لیکل شوي، د بیلګې په توګه، په کتاب کې . که تاسو نه غواړئ ژور ته لاړ شئ او تاسو په VM کې نصب شوي OS باندې د جواز ورکولو محدودیتونه نلرئ، په VM کې ډیری مجازی ساکټونه جوړ کړئ، په یو وخت کې یو اصلي. تاسو به ډیر له لاسه ورنکړئ :)
دا ټول زما لپاره د CPU په اړه دي. پوښتنې وکړئ. په راتلونکې برخه کې به زه د رام په اړه وغږیږم.
ګټور لینکونه
سرچینه: www.habr.com