پدې مقاله کې ، موږ به په vSphere کې د تصادفي لاسرسي حافظې (RAM) د فعالیت کاونټرونو په اړه وغږیږو.
داسې بریښي چې د حافظې سره هرڅه د پروسیسر په پرتله خورا روښانه دي: که چیرې VM د فعالیت ستونزې ولري ، نو دا سخته ده چې دوی ته پام ونه کړئ. مګر که دوی څرګند شي، نو د دوی سره معامله کول خورا ستونزمن دي. مګر لومړی شیان لومړی.
یو څه تیوری
د مجازی ماشینونو RAM د هغه سرور له حافظې څخه اخیستل شوی چې VMs یې پرمخ وړي. دا خورا څرګند دی :). که چیرې د سرور RAM د هرچا لپاره کافي نه وي، ESXi د RAM مصرف غوره کولو لپاره د حافظې د بیرته راګرځولو تخنیکونو کارول پیل کوي. که نه نو، د VM عملیاتي سیسټمونه به د RAM لاسرسي غلطیو سره ټکر شي.
د ESXi کارولو کوم تخنیکونه د رام بار پورې اړه لري پریکړه کوي:
د حافظې حالت
سرحد
کړنې
د عالي
400% دقیقې وړیا
پورتنۍ حد ته رسیدو وروسته، لوی حافظې پاڼې په کوچنیو ویشل کیږي (TPS په معیاري حالت کې کار کوي).
روښانه
100% دقیقې وړیا
لوی حافظې پاڼې په کوچنیو برخو ویشل شوي، TPS کار کولو ته اړ کیږي.
نرم
64% دقیقې وړیا
TPS + بالون
سخت
32% دقیقې وړیا
TPS + کمپریس + سویپ
ټیټ
16% دقیقې وړیا
کمپریس + سویپ + بلاک
minFree هغه رام دی چې د هایپروایزر کار کولو لپاره اړین دی.
مخکې له دې چې د ESXi 4.1 ټول شموله وي، minFree د ډیفالټ لخوا ټاکل شوی و - د سرور RAM 6٪ (سلنه په ESXi کې د Mem.MinFreePct اختیار له لارې بدلیدلی شي). په وروستیو نسخو کې، په سرورونو کې د حافظې د اندازې د زیاتوالي له امله، minFree د کوربه حافظې د اندازې پراساس محاسبه کول پیل کړل، نه د ثابت فیصدي په توګه.
minFree (default) ارزښت په لاندې ډول محاسبه کیږي:
د حافظې سلنه د minFree لپاره ساتل شوې
د حافظې سلسله
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
پاتې حافظه
د مثال په توګه، د 128 GB رام سره د سرور لپاره، د MinFree ارزښت به دا وي:
منفري = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
اصلي ارزښت ممکن د څو سوو MB لخوا توپیر ولري ، دا په سرور او رام پورې اړه لري.
د حافظې سلنه د minFree لپاره ساتل شوې
د حافظې سلسله
د 128 GB لپاره ارزښت
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
پاتې حافظه (100GB)
1024 MB
عموما، د تولیدي موقفونو لپاره، یوازې لوړ حالت نورمال ګڼل کیدی شي. د ازموینې او پراختیا بنچونو لپاره، پاک/نرم حالتونه ممکن د منلو وړ وي. که چیرې په کوربه کې رام له 64٪ MinFree څخه کم وي ، نو بیا VMs چې پدې کې روان دي یقینا د فعالیت ستونزې لري.
په هر حالت کې، د حافظې د بیرته راګرځولو ځانګړي تخنیکونه پلي کیږي، د TPS سره پیل کیږي، کوم چې په عملي توګه د VM فعالیت اغیزه نه کوي، او د بدلون سره پای ته رسیږي. زه به تاسو ته د دوی په اړه نور څه ووایم.
د شفاف پاڼې شریکول (TPS). TPS، په عمدي توګه، په سرور کې د مجازی ماشین حافظې پاڼو نقل کول دي.
ESXi د مخونو د هش مجموعې په شمیرلو او پرتله کولو سره د مجازی ماشین RAM ورته پا pagesې لټوي ، او نقل شوي پا pagesې لرې کوي ، د سرور فزیکي حافظه کې ورته ورته پا pagesو لینکونو سره ځای په ځای کوي. د پایلې په توګه، د فزیکي حافظې مصرف کم شوی او د حافظې ځینې ګډون د لږ یا هیڅ فعالیت کمولو سره ترلاسه کیدی شي.
دا میکانیزم یوازې د 4 KB حافظې پاڼو (کوچنیو مخونو) لپاره کار کوي. هایپروایزر حتی هڅه نه کوي چې د 2 MB (لوی مخونو) پاڼې کم کړي: د دې اندازې ورته ورته پاڼو موندلو چانس خورا ښه ندی.
په ډیفالټ ډول، ESXi لویو پاڼو ته حافظه تخصیص کوي. په کوچنیو پاڼو کې د لویو پاڼو ماتول پیل کیږي کله چې د لوړ حالت حد ته ورسیږي او مجبور کیږي کله چې پاک حالت ته ورسیږي (د هایپروایزر حالت جدول وګورئ).
که تاسو غواړئ چې TPS د کوربه RAM ډکولو ته انتظار کولو پرته کار پیل کړي، په پرمختللي اختیارونو ESXi کې تاسو اړتیا لرئ ارزښت وټاکئ "Mem.AllocGuestLargePage" تر 0 (ډیفالټ 1). بیا د مجازی ماشینونو لپاره د لوی حافظې پا pagesو تخصیص به غیر فعال شي.
د دسمبر 2014 راهیسې، د ESXi په ټولو خپرونو کې، د VMs ترمنځ TPS د ډیفالټ په توګه غیر فعال شوی، ځکه چې یو زیانمنتیا وموندل شوه چې په تیوریکي توګه د یو VM څخه د بل VM رام ته د لاسرسي اجازه ورکوي. تفصيل دلته. زه د TPS زیانمننې څخه د ګټې اخیستنې د عملي تطبیق په اړه معلومات نه لرم.
د TPS پالیسي د پرمختللي اختیار له لارې کنټرول کیږي "Mem.ShareForceSalting" په ESXi کې:
0 - Inter-VM TPS. TPS د مختلفو VM پاڼو لپاره کار کوي؛
1 - د VM لپاره TPS په VMX کې د ورته "sched.mem.pshare.salt" ارزښت سره؛
2 (ډیفالټ) - Intra-VM TPS. TPS د VM دننه پاڼو لپاره کار کوي.
دا یقینا معنی لري چې لوی پا pagesې بندې کړئ او د ازموینې بنچونو کې د انټر VM TPS چالان کړئ. دا د ورته VM لوی شمیر سره د سټینډونو لپاره هم کارول کیدی شي. د مثال په توګه، د VDI سره په سټینډونو کې، په فزیکي حافظه کې سپما کولی شي لسګونه سلنې ته ورسیږي.
د حافظې بالون کول. بالون کول نور د TPS په څیر د VM عملیاتي سیسټم لپاره دومره بې ضرر او شفاف تخنیک نه دی. مګر د مناسب غوښتنلیک سره ، تاسو کولی شئ ژوند وکړئ او حتی د بالونینګ سره کار وکړئ.
د Vmware Tools سره یوځای، د بالون ډرایور (aka vmmemctl) په نوم یو ځانګړی ډرایور په VM کې نصب شوی. کله چې هایپروایزر د فزیکي حافظې له لاسه ورکولو پیل وکړي او نرم حالت ته ننوځي، ESXi د VM څخه غوښتنه کوي چې د دې بالون ډرایور له لارې غیر کارول شوي RAM بیرته ترلاسه کړي. چلوونکی، په بدل کې، د عملیاتي سیسټم په کچه کار کوي او له هغې څخه د وړیا حافظې غوښتنه کوي. هایپروایزر ګوري چې د بالون ډرایور د فزیکي حافظې کومې پاڼې نیولې دي ، حافظه له مجازی ماشین څخه اخلي او کوربه ته یې راستوي. د OS په عملیاتو کې کومه ستونزه شتون نلري ، ځکه چې د OS په کچه حافظه د بالون ډرایور لخوا نیول شوې. د ډیفالټ بالون ډرایور کولی شي د VM حافظې تر 65٪ پورې واخلي.
که چیرې د VMware اوزار په VM کې ندي نصب شوي یا بالونینګ غیر فعال وي (زه وړاندیز نه کوم ، مګر شتون لري :)، هایپروایزر سمدلاسه د حافظې لرې کولو خورا سخت تخنیکونو ته واړوي. پایله: ډاډ ترلاسه کړئ چې د VMware اوزار په VM کې دي.
د بالون ډرایور عملیات د OS څخه د VMware اوزار له لارې چیک کیدی شي.
د حافظې کمپریشن. دا تخنیک کارول کیږي کله چې ESXi سخت حالت ته ورسیږي. لکه څنګه چې نوم معنی لري، ESXi هڅه کوي د 4KB پاڼې رام 2KB ته راټیټ کړي او پدې توګه د سرور فزیکي حافظه کې یو څه ځای خالي کړي. دا تخنیک د پام وړ د VM RAM پا pagesو مینځپانګو ته د لاسرسي وخت ډیروي ، ځکه چې پاڼه باید لومړی غیر کمپریس شي. ځینې وختونه ټولې پاڼې د فشار وړ ندي او پروسه پخپله یو څه وخت نیسي. له همدې امله، دا تخنیک په عمل کې خورا اغیزمن نه دی.
د حافظې بدلول. د لنډ حافظې کمپریشن مرحلې وروسته ، ESXi تقریبا په لازمي ډول (که چیرې VMs د نورو کوربه توب لپاره نه وي وتلي یا بند شوي وي) به سویپ کولو ته لاړ شي. او که چیرې ډیر لږ حافظه پاتې وي (ټيټ حالت) ، نو بیا هایپروایسر هم VM ته د حافظې پا pagesو تخصیص بندوي ، کوم چې د VM میلمه OS کې ستونزې رامینځته کولی شي.
دلته د بدلولو څرنګوالی دی. کله چې تاسو یو مجازی ماشین چالان کړئ، د .vswp توسیع سره یو فایل د هغې لپاره رامینځته کیږي. دا د VM غیر محفوظ شوي RAM سره په اندازه کې مساوي دی: دا د ترتیب شوي او خوندي حافظې ترمینځ توپیر دی. کله چې سویپنګ روان وي، ESXi په دې فایل کې د مجازی ماشین حافظې پاڼې خلاصوي او د سرور فزیکي حافظې پرځای یې کار پیل کوي. البته، دا ډول "عملي" حافظه د ریښتیني په پرتله ورو ورو د شدت څو امرونه دي، حتی که .vswp په ګړندۍ ذخیره کې وي.
د بالونینګ برعکس، کله چې غیر استعمال شوي پاڼې د VM څخه اخیستل کیږي، د بدلولو سره، هغه پاڼې چې په فعاله توګه د OS لخوا کارول کیږي یا د VM دننه غوښتنلیکونه ډیسک ته لیږدول کیدی شي. د پایلې په توګه، د VM فعالیت د یخولو نقطې ته راټیټیږي. VM په رسمي ډول کار کوي او لږترلږه دا د OS څخه په سمه توګه غیر فعال کیدی شي. که صبر کوئ 😉
که VMs سویپ ته لاړ شي، دا یو غیر معمولي حالت دی، کوم چې د امکان په صورت کې غوره مخنیوی کیږي.
د کلیدي VM حافظې فعالیت کاونټرونه
نو موږ اصلي ټکي ته ورسیدو. په VM کې د حافظې حالت څارلو لپاره، لاندې شمیرونکي شتون لري:
د فعالو - د RAM اندازه (KB) ښیې چې VM په تیرو اندازه کولو دوره کې ورته لاسرسی موندلی.
کارېدنه - د فعال په څیر، مګر د VM ترتیب شوي رام د فیصدي په توګه. د لاندې فورمول په کارولو سره حساب شوی: فعال ÷ مجازی ماشین ترتیب شوی حافظه اندازه.
لوړ کارول او فعال، په ترتیب سره، تل د VM فعالیت ستونزو شاخص نه وي. که چیرې VM په کلکه حافظه وکاروي (لږترلږه دې ته لاسرسی ومومي) ، دا پدې معنی ندي چې کافي حافظه شتون نلري. بلکه، دا یو فرصت دی چې وګورئ په OS کې څه پیښیږي.
د VMs لپاره د حافظې کارولو معیاري الارم شتون لري:
شریک شوی - د VM RAM مقدار د TPS په کارولو سره نقل شوی (د VM دننه یا د VMs ترمینځ).
ورکړل شوی - د فزیکي کوربه حافظې مقدار (KB) چې VM ته ورکړل شوی و. شریکول شامل دي.
مصرف شوی (منظور شوی - شریک شوی) - د فزیکي حافظې مقدار (KB) چې VM له کوربه څخه مصرفوي. شریکول شامل ندي.
که چیرې د VM حافظې برخه د کوربه فزیکي حافظې څخه نه ورکول کیږي ، مګر د سویپ فایل څخه ورکول کیږي ، یا حافظه له VM څخه د بالون ډرایور له لارې اخیستل کیږي ، دا مقدار په ورکړل شوي او مصرف شوي حساب کې نه اخیستل کیږي.
لوړ ورکړل شوي او مصرف شوي ارزښتونه په بشپړ ډول نورمال دي. عملیاتي سیسټم په تدریجي ډول د هایپروایزر څخه حافظه اخلي او بیرته نه ورکوي. د وخت په تیریدو سره، په فعاله توګه روان VM کې، د دې کاونټرو ارزښتونه د ترتیب شوي حافظې مقدار ته رسیږي، او هلته پاتې کیږي.
صفر - د VM RAM (KB) مقدار، کوم چې صفرونه لري. دا ډول حافظه د Hypervisor لخوا وړیا ګڼل کیږي او نورو مجازی ماشینونو ته ورکول کیدی شي. وروسته له دې چې میلمه OS د صفر حافظې ته یو څه ولیکي، دا مصرف ته ځي او بیرته نه راستنیږي.
ساتل شوی سر - د VM RAM مقدار، (KB) د VM عملیاتو لپاره د هایپروایزر لخوا ساتل شوی. دا یو کوچنی مقدار دی، مګر دا باید په کوربه کې شتون ولري، که نه نو VM به پیل نشي.
غره - د بالون ډرایور په کارولو سره د VM څخه نیول شوي RAM (KB) اندازه.
فشار شوی - د RAM اندازه (KB) چې فشار شوی و.
بدل شوی - د رام (KB) مقدار چې په سرور کې د فزیکي حافظې نشتوالي له امله ډیسک ته لیږدول شوی.
بالون او نور د حافظې د بیرته راګرځولو تخنیکونو شمیر صفر دی.
دا څنګه د حافظې کاونټرونو سره ګراف د 150 GB رام سره د نورمال کاري VM لپاره ښکاري.
په لاندې ګراف کې، VM ښکاره ستونزې لري. د ګراف لاندې، تاسو لیدلی شئ چې د دې VM لپاره، د رام سره کار کولو لپاره ټول تشریح شوي تخنیکونه کارول شوي. د دې VM لپاره بالون د مصرف شوي څخه خورا لوی دی. په حقیقت کې، VM د ژوندي په پرتله ډیر مړ دی.
ESXTOP
لکه څنګه چې د CPU سره، که موږ غواړو په کوربه کې وضعیت په چټکۍ سره ارزونه وکړو، او همدارنګه د 2 ثانیو پورې وقفې سره د هغې متحرکات، موږ باید ESXTOP وکاروو.
د حافظې لخوا د ESXTOP سکرین د "m" کیلي سره ویل کیږي او داسې ښکاري (د B, D, H, J, K, L, O ساحې غوره شوي):
لاندې پیرامیټونه به زموږ لپاره په زړه پوري وي:
Mem overcommit اوسط - په کوربه کې د 1، 5 او 15 دقیقو لپاره د حافظې د څارنې اوسط ارزښت. که دا د صفر څخه پورته وي، نو دا یو فرصت دی چې وګورئ څه پیښیږي، مګر تل د ستونزو شاخص نه وي.
په لیکو کې PMEM/MB и VMKMEM/MB - د سرور فزیکي حافظې او VMkernel ته موجود حافظې په اړه معلومات. دلته په زړه پورې تاسو کولی شئ د minfree ارزښت وګورئ (په MB کې)، په حافظه کې د کوربه حالت (زموږ په قضیه کې، لوړ).
په لیکه کې NUMA/MB تاسو کولی شئ د NUMA نوډونو (ساکټونو) لخوا د رام توزیع وګورئ. په دې مثال کې، ویش نا برابر دی، کوم چې په اصولو کې خورا ښه نه دی.
لاندې د حافظې د بیرته راګرځولو تخنیکونو په اړه عمومي سرور احصایې دي:
PSHARE/MB د TPS احصایې دي؛
SWAP/MB - د کارونې احصایې بدل کړئ؛
ZIP/MB - د حافظې پاڼې کمپریشن احصایې؛
MEMCTL/MB - د بالون ډرایور کارولو احصایې.
د انفرادي VMs لپاره، موږ ممکن د لاندې معلوماتو سره علاقه ولرو. ما د VM نومونه پټ کړل ترڅو لیدونکي ګډوډ نه کړي :). که د ESXTOP میټریک په vSphere کې کاونټر ته ورته وي، زه ورته کاونټر ورکوم.
MEMSZ - د حافظې مقدار چې په VM (MB) کې ترتیب شوی.
MEMSZ = GRANT + MCTLSZ + SWCUR + ناڅاپه.
بخښنه - MB ته ورکړل شوی.
TCHD - په MB کې فعال.
MCTL؟ - ایا د بالون ډرایور په VM کې نصب شوی.
MCTLSZ - بالون ته MB.
MCTLGT - د RAM اندازه (MB) چې ESXi غواړي د بالون ډرایور (Memctl هدف) له لارې له VM څخه واخلي.
MCTLMAX - د RAM اعظمي اندازه (MB) چې ESXi کولی شي له VM څخه د بالون ډرایور له لارې واخلي.
SWCUR - د سویپ فایل څخه VM ته د RAM اوسنی مقدار (MB) تخصیص شوی.
S.W.G.T. - د RAM اندازه (MB) چې ESXi غواړي د سویپ فایل (د سویپ هدف) څخه VM ته ورکړي.
همچنان ، د ESXTOP له لارې ، تاسو کولی شئ د VM د NUMA ټوپولوژي په اړه نور تفصيلي معلومات وګورئ. د دې کولو لپاره، D، G ساحې غوره کړئ:
کوچنی - NUMA نوډونه په کوم کې چې VM موقعیت لري. دلته تاسو سمدلاسه پراخه vm لیدلی شئ ، کوم چې په یو NUMA نوډ کې نه فټ کیږي.
NRMEM - VM څومره میګابایټ حافظه له لرې NUMA نوډ څخه اخلي.
NLMEM - VM د ځایی NUMA نوډ څخه څومره میګابایټ حافظه اخلي.
N%L - په محلي NUMA نوډ کې د VM حافظې سلنه (که له 80٪ څخه کم وي، د فعالیت ستونزې ممکن واقع شي).
په Hypervisor کې حافظه
که چیرې د هایپروایزر لپاره د CPU شمیرونکي معمولا د ځانګړې علاقې وړ نه وي ، نو وضعیت د حافظې سره بدلیږي. په VM کې د حافظې لوړه کارول تل د فعالیت ستونزه نه په ګوته کوي ، مګر په هایپروایزر کې د حافظې لوړه کارول د حافظې مدیریت تخنیکونه رامینځته کوي او په VM کې د فعالیت ستونزې رامینځته کوي. د کوربه حافظې کارولو الارمونه باید وڅارل شي ترڅو د VM بدلیدو څخه مخنیوی وشي.
بدلول
که یو VM په سویپ کې وي، د هغې فعالیت خورا کم شوی. په کوربه کې د وړیا RAM څرګندیدو وروسته د بالون کولو او کمپریشن نښې په چټکۍ سره ورک کیږي ، مګر مجازی ماشین د سویپ څخه سرور رام ته د بیرته راستنیدو لپاره بیړه نه کوي.
د ESXi 6.0 څخه دمخه ، د سویپ څخه د VM ترلاسه کولو یوازینۍ معتبره او ګړندۍ لاره د ریبوټ کول وو (د ډیر دقیق کیدو لپاره ، کانټینر بند/بند کړئ). د ESXi 6.0 سره پیل کول ، که څه هم خورا رسمي ندي ، د سویپ څخه د VM لرې کولو لپاره کاري او باوري لاره راڅرګنده شوې. په یوه کنفرانس کې ، زه وکولی شم د VMware انجینرانو څخه د CPU مهالویش مسؤل سره خبرې وکړم. هغه تایید کړه چې میتود خورا کار او خوندي دی. زموږ په تجربه کې، له دې سره کومه ستونزه نه وه.
د سویپ څخه د VM لرې کولو لپاره اصلي حکمونه ډنکن ایپینګ. زه به تفصیلي توضیحات تکرار نه کړم ، یوازې د دې کارولو مثال ورکړئ. لکه څنګه چې تاسو په سکرین شاټ کې لیدلی شئ، د ټاکل شوي کمانډونو اجرا کولو څخه یو څه وخت وروسته، سویپ په VM کې ورک کیږي.
د ESXi حافظې مدیریت لارښوونې
په نهایت کې ، دلته ځینې لارښوونې دي چې تاسو سره به د رام له امله د VM فعالیت سره د ستونزو مخنیوي کې مرسته وکړي:
- په تولیدي کلسترونو کې د حافظې اضافي ګډون څخه ډډه وکړئ. دا د پام وړ ده چې تل په کلستر کې ~ 20-30٪ وړیا حافظه ولرئ ترڅو DRS (او مدیر) د چلولو لپاره خونه ولري، او VMs د مهاجرت پرمهال سویپ ته نه ځي. همدارنګه، د خطا زغم لپاره د حاشیې په اړه مه هېروئ. دا ناخوښه ده کله چې یو سرور ناکام شي او VM د HA په کارولو سره ریبوټ شي ، ځینې ماشینونه هم سویپ ته ځي.
- په خورا قوي زیربنا کې ، هڅه مه کوئ چې د کوربه حافظې نیمایي څخه ډیر سره VMs رامینځته کړئ. دا به بیا د DRS سره مرسته وکړي چې پرته له کومې ستونزې د کلستر سرورونو کې مجازی ماشینونه توزیع کړي. دا قاعده، البته، نړیواله نه ده :).
- د کوربه حافظې کارولو الارم لپاره وګورئ.
- په VM کې د VMware اوزار نصب کول مه هیروئ او بالونینګ بند مه کوئ.
- د Inter-VM TPS فعالولو او په VDI او ازموینې چاپیریال کې د لویو پاڼو غیر فعالولو په اړه غور وکړئ.
- که VM د فعالیت مسلو سره مخ وي، وګورئ چې وګورئ دا د ریموټ NUMA نوډ څخه حافظه کاروي.
- خپل VM ژر تر ژره له سویپ څخه لرې کړئ! د نورو شیانو په مینځ کې ، که VM په سویپ کې وي ، د څرګند دلیلونو لپاره ، د ذخیره کولو سیسټم زیان لري.
دا ټول زما لپاره د رام په اړه دي. لاندې د هغو کسانو لپاره اړونده مقاله ده څوک چې غواړي توضیحاتو ته لاړ شي. راتلونکی مقاله به storadzh ته وقف شي.
ګټور لینکونه
سرچینه: www.habr.com